summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInvocation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Convert some ObjC msgSends to runtime calls."Pete Cooper2016-03-211-3/+0
| | | | | | | | | | | | | | This reverts commit r263607. This change caused more objc_retain/objc_release calls in the IR but those are then incorrectly optimized by the ARC optimizer. Work is going to have to be done to ensure the ARC optimizer doesn't optimize user written RR, but that should land before this change. This change will also need to be updated to take account for any changes required to ensure that user written calls to RR are distinct from those inserted by ARC. llvm-svn: 263984
* Reapply [2] [VFS] Add 'overlay-relative' field to YAML filesBruno Cardoso Lopes2016-03-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r261552 and r263748. Fixed testcase to reapply. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263893
* Add -fnative-half-arguments-and-returnsPirama Arumuga Nainar2016-03-181-1/+6
| | | | | | | | | | | | | | | | | | Summary: r246764 handled __fp16 arguments and returns for AAPCS, but skipped this handling for OpenCL. Simlar to OpenCL, RenderScript also handles __fp16 type natively. This patch adds the -fnative-half-arguments-and-returns command line flag to allow such languages to skip this coercion of __fp16. Reviewers: srhines, olista01 Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18138 llvm-svn: 263795
* Revert "Reapply [VFS] Add 'overlay-relative' field to YAML files"Bruno Cardoso Lopes2016-03-171-2/+2
| | | | | | | | | Tests failing on http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/46102 This reverts commit a1683cd6c9e07359c09f86e98a4db6b4e1bc51fc. llvm-svn: 263750
* Reapply [VFS] Add 'overlay-relative' field to YAML filesBruno Cardoso Lopes2016-03-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r261552. The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 263748
* Convert some ObjC msgSends to runtime calls.Pete Cooper2016-03-161-0/+3
| | | | | | | | | | | | | | It is faster to directly call the ObjC runtime for methods such as retain/release instead of sending a message to those functions. This patch adds support for converting messages to retain/release/alloc/autorelease to their equivalent runtime calls. Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions. Reviewed by John McCall. Differential Revision: http://reviews.llvm.org/D14737 llvm-svn: 263607
* Make it possible for AST plugins to enable themselves by defaultJohn Brawn2016-03-151-10/+2
| | | | | | | | | | | | Currently when an AST plugin is loaded it must then be enabled by passing -plugin pluginname or -add-plugin pluginname to the -cc1 command line. This patch adds a method to PluginASTAction which allows it to declare that the action happens before, instead of, or after the main AST action, plus the relevant changes to make the plugin action happen at that time automatically. Differential Revision: http://reviews.llvm.org/D17959 llvm-svn: 263546
* Restrict the hack from r263429 to asan and msan.Benjamin Kramer2016-03-151-2/+4
| | | | | | | The other sanitizers don't have backend passes that rely on value names. Avoid paying the compile time cost of names there. llvm-svn: 263541
* [ThinLTO] Clang side of renaming of function index (NFC)Teresa Johnson2016-03-151-1/+1
| | | | | | | | | This is the companion to an LLVM patch that renamed the function index data structures and files to use the more general module summary index. (Recommit after fixing LLVM side to add back missed file) llvm-svn: 263514
* Revert "[ThinLTO] Clang side of renaming of function index (NFC)"Teresa Johnson2016-03-141-1/+1
| | | | | | This reverts commit r263491. Missed a file on the LLVM side. llvm-svn: 263494
* [ThinLTO] Clang side of renaming of function index (NFC)Teresa Johnson2016-03-141-1/+1
| | | | | | | This is the companion to an LLVM patch that renamed the function index data structures and files to use the more general module summary index. llvm-svn: 263491
* [OpenMP] Replace offloading option that start with -o with -fo.Samuel Antao2016-03-141-2/+2
| | | | | | | | | | | | | | | Summary: The current offloading implementation is using -omptargets and -omp-host-ir-file-path options in the frontend. This causes the user a lot of trouble due to to the conflicts with the -o option. E.g. if the user misspells omptargets he will end up with a file with a weird name. This patches replaces these two options with -fomptargets and -fomp-host-ir-file-path to avoid these issues, and it is also more consistent with the other options like -fopenmp. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: cfe-commits, caomhin, fraggamuffin Differential Revision: http://reviews.llvm.org/D18112 llvm-svn: 263442
* [Frontend] Disable value name discarding for all sanitizers.Benjamin Kramer2016-03-141-6/+7
| | | | | | | | ASan also relies on names on allocas and will emit unhelpful output if they're not present. Just force-enable value names for now. Should unbreak release builds of asan. llvm-svn: 263429
* Temporarily make discard value names depend on whether or not we'reEric Christopher2016-03-141-1/+6
| | | | | | | | | | trying to track origins in the memory sanitizer since the backend instrumentation pass currently takes names from the Instruction. Fixes all of the origin tracking tests in compiler-rt after the -discard-value-name option was added. llvm-svn: 263412
* Remove compile time PreserveName in favor of a runtime cc1 ↵Mehdi Amini2016-03-131-0/+1
| | | | | | | | | | | | | | | | | | | | -discard-value-names option Summary: This flag is enabled by default in the driver when NDEBUG is set. It is forwarded on the LLVMContext to discard all value names (but GlobalValue) for performance purpose. This an improved version of D18024 Reviewers: echristo, chandlerc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18127 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263394
* [PGO] Change profile use cc1 option to handle IR level profilesRong Xu2016-03-021-26/+47
| | | | | | | | | | | | | | | | | | This patch changes cc1 option for PGO profile use from -fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>. -fprofile-instr-use=<path> is now a driver only option. In addition to decouple the cc1 option from the driver level option, this patch also enables IR level profile use. cc1 option handling now reads the profile header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM} -- this is a common enum for -fprofile-instrument={}, for the profile instrumentation), and invoke the pipeline to enable the respective PGO use pass. Reviewers: silvas, davidxl Differential Revision: http://reviews.llvm.org/D17737 llvm-svn: 262515
* clang-cl: Implement initial limited support for precompiled headers.Nico Weber2016-03-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the gcc precompiled header model, one explicitly runs clang with `-x c++-header` on a .h file to produce a gch file, and then includes the header with `-include foo.h` and if a .gch file exists for that header it gets used. This is documented at http://clang.llvm.org/docs/UsersManual.html#precompiled-headers cl.exe's model is fairly different, and controlled by the two flags /Yc and /Yu. A pch file is generated as a side effect of a regular compilation when /Ycheader.h is passed. While the compilation is running, the compiler keeps track of #include lines in the main translation unit and writes everything up to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells the compiler to skip all code in the main TU up to and including `#include "header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu without an argument, in that case a `#pragma hrdstop` takes the role of controlling the point where pch ends and real code begins.) This patch implements limited support for this in that it requires the pch header to be passed as a /FI force include flag – with this restriction, it can be implemented almost completely in the driver with fairly small amounts of code. For /Yu, this is trivial, and for /Yc a separate pch action is added that runs before the actual compilation. After r261774, the first failing command makes a compilation stop – this means if the pch fails to build the main compilation won't run, which is what we want. However, in /fallback builds we need to run the main compilation even if the pch build fails so that the main compilation's fallback can run. To achieve this, add a ForceSuccessCommand that pretends that the pch build always succeeded in /fallback builds (the main compilation will then fail to open the pch and run the fallback cl.exe invocation). If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl will now emit a "not implemented yet; flag ignored" warning that can be disabled using -Wno-clang-cl-pch. Since clang-cl doesn't yet serialize some important things (most notably `pragma comment(lib, ...)`, this feature is disabled by default and only enabled by an internal driver flag. Once it's more stable, this internal flag will disappear. (The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it does. Implementing support for this should be possible with the approach in this patch with minimal frontend changes by passing a --stop-at / --start-at flag from the driver to the frontend. This is left for a follow-up. I don't think we ever want to support `#pragma hdrstop`, and supporting it with this approach isn't easy: This approach relies on the driver knowing the pch filename in advance, and `#pragma hdrstop(out.pch)` can set the output filename, so the driver can't know about it in advance.) clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe would put them, but the pch file format is of course incompatible. This has ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in /fallback builds. http://reviews.llvm.org/D17695 llvm-svn: 262420
* [PGO] clang cc1 option change to enable IR level instrumentationRong Xu2016-02-291-2/+7
| | | | | | | | | | | This patch expands cc1 option -fprofile-instrument= with a new value: -fprofile-instrument=llvm which enables IR level PGO instrumentation. Reviewers: davidxl, silvas Differential Revision: http://reviews.llvm.org/D17622 llvm-svn: 262239
* Add whole-program vtable optimization feature to Clang.Peter Collingbourne2016-02-241-0/+3
| | | | | | | | | This patch introduces the -fwhole-program-vtables flag, which enables the whole-program vtable optimization feature (D16795) in Clang. Differential Revision: http://reviews.llvm.org/D16821 llvm-svn: 261767
* Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix ↵Bruno Cardoso Lopes2016-02-231-2/+2
| | | | | | | | | | | | | | | call to getVFSFromYAML in unittests" This reverts commit r261552 and r261556 because of failing unittests on windows: Failing Tests (4): Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName llvm-svn: 261613
* [VFS] Add 'overlay-relative' field to YAML filesBruno Cardoso Lopes2016-02-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VFS overlay mapping between virtual paths and real paths is done through the 'external-contents' entries in YAML files, which contains hardcoded paths to the real files. When a module compilation crashes, headers are dumped into <name>.cache/vfs directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script generated for reproduction uses -ivfsoverlay pointing to file to gather the mapping between virtual paths and files inside <name>.cache/vfs. Currently, we are only capable of reproducing such crashes in the same machine as they happen, because of the hardcoded paths in 'external-contents'. To be able to reproduce a crash in another machine, this patch introduces a new option in the VFS yaml file called 'overlay-relative'. When it's equal to 'true' it means that the provided path to the YAML file through the -ivfsoverlay option should also be used to prefix the final path for every 'external-contents'. Example, given the invocation snippet "... -ivfsoverlay <name>.cache/vfs/vfs.yaml" and the following entry in the yaml file: "overlay-relative": "true", "roots": [ ... "type": "directory", "name": "/usr/include", "contents": [ { "type": "file", "name": "stdio.h", "external-contents": "/usr/include/stdio.h" }, ... Here, a file manager request for virtual "/usr/include/stdio.h", that will map into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h. This is a useful feature for debugging module crashes in machines other than the one where the error happened. Differential Revision: http://reviews.llvm.org/D17457 rdar://problem/24499339 llvm-svn: 261552
* [MSVC Compat] Implement -EHc semanticsDavid Majnemer2016-02-201-0/+1
| | | | | | | The -EHc flag implicitly adds a nothrow attribute to any extern "C" function when exceptions are enabled. llvm-svn: 261425
* [modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a singleRichard Smith2016-02-191-9/+1
| | | | | | | | | | | | option. Previously these options could both be used to specify that you were compiling the implementation file of a module, with a different set of minor bugs in each case. This change removes -fmodule-implementation-of, and instead tracks a flag to determine whether we're currently building a module. -fmodule-name now behaves the same way that -fmodule-implementation-of previously did. llvm-svn: 261372
* [sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar ↵Kostya Serebryany2016-02-171-0/+1
| | | | | | to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may be able to use this flag with AFL too llvm-svn: 261159
* Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow ↵Samuel Antao2016-02-081-1/+18
| | | | | | | | specialized code generation for different devices. This was reverted by r260036, but was not the cause of the problem in the buildbot. llvm-svn: 260106
* Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized ↵Renato Golin2016-02-071-18/+1
| | | | | | | | code generation for different devices." This reverts commit r259985, as it still fails one buildbot. llvm-svn: 260036
* Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code ↵Samuel Antao2016-02-061-1/+18
| | | | | | | | generation for different devices. This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated. llvm-svn: 259985
* Revert r259977 - [OpenMP] Reorganize code to allow specialized code ↵Samuel Antao2016-02-061-18/+1
| | | | | | | | generation for different devices. It triggered some problem in the configuration related with zlib and exposed in the driver. llvm-svn: 259984
* [OpenMP] Reorganize code to allow specialized code generation for different ↵Samuel Antao2016-02-061-1/+18
| | | | | | | | | | | | | | | | | | | | | | | devices. Summary: Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation. This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it. In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done. In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not. Let me know comments suggestions you may have. Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski Differential Revision: http://reviews.llvm.org/D16784 llvm-svn: 259977
* Eliminate an unnecessary enum, use the LLVM version. NFCPaul Robinson2016-02-051-4/+4
| | | | llvm-svn: 259950
* [PGO] cc1 option name change for profile instrumentationRong Xu2016-02-041-3/+22
| | | | | | | | | | | | This patch changes cc1 option -fprofile-instr-generate to an enum option -fprofile-instrument={clang|none}. It also changes cc1 options -fprofile-instr-generate= to -fprofile-instrument-path=. The driver level option -fprofile-instr-generate and -fprofile-instr-generate= remain intact. This change will pave the way to integrate new PGO instrumentation in IR level. Review: http://reviews.llvm.org/D16730 llvm-svn: 259811
* Move DebugInfoKind into its own header to cut the cyclic dependency edge ↵Benjamin Kramer2016-02-021-6/+6
| | | | | | from Driver to Frontend. llvm-svn: 259489
* Do not define GXX_RTTI macro for C.Yunzhong Gao2016-01-261-1/+1
| | | | | | | | This is same as GCC behavior (tested with GCC 4.8.2). Differential Revision: http://reviews.llvm.org/D16365 llvm-svn: 258850
* [CUDA] Add -fcuda-allow-variadic-functions.Justin Lebar2016-01-261-0/+3
| | | | | | | | | | | | | | | | | Summary: Turns out the variadic function checking added in r258643 was too strict for some existing users; give them an escape valve. When -fcuda-allow-variadic-functions is passed, the front-end makes no attempt to disallow C-style variadic functions. Calls to va_arg are still not allowed. Reviewers: tra Subscribers: cfe-commits, jhen, echristo, bkramer Differential Revision: http://reviews.llvm.org/D16559 llvm-svn: 258822
* Introduce -fsanitize-stats flag.Peter Collingbourne2016-01-161-0/+2
| | | | | | | | | This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16175 llvm-svn: 257971
* Module debugging: Make the module format part of the module hash insteadAdrian Prantl2016-01-121-2/+5
| | | | | | | | | | of the file name. This is consistent with how other HeaderSearchOptions are handled. Due to the other inputs of the module hash (revision number) this is not really testable in a meaningful way. llvm-svn: 257520
* Accidentally removed part of the file header. Restoring it back.Ekaterina Romanova2016-01-101-1/+1
| | | | llvm-svn: 257291
* [Driver] Add support for -fno-builtin-foo options.Chad Rosier2016-01-061-1/+20
| | | | | | | Addresses PR4941 and rdar://6756912. http://reviews.llvm.org/D15195 llvm-svn: 256937
* [OpenMP] Reapply rL256842: [OpenMP] Offloading descriptor registration and ↵Samuel Antao2016-01-061-0/+24
| | | | | | | | | | | | device codegen. This patch attempts to fix the regressions identified when the patch was committed initially. Thanks to Michael Liao for identifying the fix in the offloading metadata generation related with side effects in evaluation of function arguments. llvm-svn: 256933
* Avoid assert failure on some invalid cc1 options.Douglas Katzman2016-01-061-8/+19
| | | | | | | | Addressing review comment in D13221. Differential Revision: http://reviews.llvm.org/D15882 llvm-svn: 256897
* [OpenMP] Revert rL256842: [OpenMP] Offloading descriptor registration and ↵Samuel Antao2016-01-051-24/+0
| | | | | | | | device codegen. It was causing two regression, so I'm reverting until the cause is found. llvm-svn: 256858
* [OpenMP] Offloading descriptor registration and device codegen.Samuel Antao2016-01-051-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In order to offloading work properly two things need to be in place: - a descriptor with all the offloading information (device entry functions, and global variable) has to be created by the host and registered in the OpenMP offloading runtime library. - all the device functions need to be emitted for the device and a convention has to be in place so that the runtime library can easily map the host ID of an entry point with the actual function in the device. This patch adds support for these two things. However, only entry functions are being registered given that 'declare target' directive is not yet implemented. About offloading descriptor: The details of the descriptor are explained with more detail in http://goo.gl/L1rnKJ. Basically the descriptor will have fields that specify the number of devices, the pointers to where the device images begin and end (that will be defined by the linker), and also pointers to a the begin and end of table whose entries contain information about a specific entry point. Each entry has the type: ``` struct __tgt_offload_entry{ void *addr; char *name; int64_t size; }; ``` and will be implemented in a pre determined (ELF) section `.omp_offloading.entries` with 1-byte alignment, so that when all the objects are linked, the table is in that section with no padding in between entries (will be like a C array). The code generation ensures that all `__tgt_offload_entry` entries are emitted in the same order for both host and device so that the runtime can have the corresponding entries in both host and device in same index of the table, and efficiently implement the mapping. The resulting descriptor is registered/unregistered with the runtime library using the calls `__tgt_register_lib` and `__tgt_unregister_lib`. The registration is implemented in a high priority global initializer so that the registration happens always before any initializer (that can potentially include target regions) is run. The driver flag -omptargets= was created to specify a comma separated list of devices the user wants to support so that the new functionality can be exercised. Each device is specified with its triple. About target codegen: The target codegen is pretty much straightforward as it reuses completely the logic of the host version for the same target region. The tricky part is to identify the meaningful target regions in the device side. Unlike other programming models, like CUDA, there are no already outlined functions with attributes that mark what should be emitted or not. So, the information on what to emit is passed in the form of metadata in host bc file. This requires a new option to pass the host bc to the device frontend. Then everything is similar to what happens in CUDA: the global declarations emission is intercepted to check to see if it is an "interesting" declaration. The difference is that instead of checking an attribute, the metadata information in checked. Right now, there is only a form of metadata to pass information about the device entry points (target regions). A class `OffloadEntriesInfoManagerTy` was created to manage all the information and queries related with the metadata. The metadata looks like this: ``` !omp_offload.info = !{!0, !1, !2, !3, !4, !5, !6} !0 = !{i32 0, i32 52, i32 77426347, !"_ZN2S12r1Ei", i32 479, i32 13, i32 4} !1 = !{i32 0, i32 52, i32 77426347, !"_ZL7fstatici", i32 461, i32 11, i32 5} !2 = !{i32 0, i32 52, i32 77426347, !"_Z9ftemplateIiET_i", i32 444, i32 11, i32 6} !3 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 99, i32 11, i32 0} !4 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 272, i32 11, i32 3} !5 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 127, i32 11, i32 1} !6 = !{i32 0, i32 52, i32 77426347, !"_Z3fooi", i32 159, i32 11, i32 2} ``` The fields in each metadata entry are (in sequence): Entry 1) an ID of the type of metadata - right now only zero is used meaning "OpenMP target region". Entry 2) a unique ID of the device where the input source file that contain the target region lives. Entry 3) a unique ID of the file where the input source file that contain the target region lives. Entry 4) a mangled name of the function that encloses the target region. Entries 5) and 6) line and column number where the target region was found. Entry 7) is the order the entry was emitted. Entry 2) and 3) are required to distinguish files that have the same function name. Entry 4) is required to distinguish different instances of the same declaration (usually templated ones) Entries 5) and 6) are required to distinguish the particular target region in body of the function (it is possible that a given target region is not an entry point - if clause can evaluate always to zero - and therefore we need to identify the "interesting" target regions. ) This patch replaces http://reviews.llvm.org/D12306. Reviewers: ABataev, hfinkel, tra, rjmccall, sfantao Subscribers: FBrygidyn, piotr.rak, Hahnfeld, cfe-commits Differential Revision: http://reviews.llvm.org/D12614 llvm-svn: 256842
* Some minor correction based on David Blaikie post-commit code review for ↵Ekaterina Romanova2015-12-241-3/+2
| | | | | | r255281. llvm-svn: 256396
* [clang-cl] Add support for /BreproDavid Majnemer2015-12-211-0/+2
| | | | | | | | | | | | The /Brepro flag controls whether or not the compiler should embed timestamps into the object file. Object files which do not embed timestamps are not suitable for incremental linking but are suitable for hermetic build systems and staged self-hosts of clang. A normal clang spelling of this flag has been added, -mincremental-linker-compatible. llvm-svn: 256204
* Recommit CC1 part of debugger tuning; pass through setting from driver to LLVM.Paul Robinson2015-12-191-0/+7
| | | | | | | | | Reapplies r256063, except instead of frugally re-using an LLVM enum, we define a Clang enum, to avoid exposing too much LLVM interface. Differential Revision: http://reviews.llvm.org/D15650 llvm-svn: 256078
* Revert r256063, it's killing clang-tools-extraPaul Robinson2015-12-191-7/+0
| | | | llvm-svn: 256066
* CC1 part of debugger tuning; pass through setting from driver to LLVM.Paul Robinson2015-12-181-0/+7
| | | | | | Differential Revision: http://reviews.llvm.org/D15650 llvm-svn: 256063
* Cross-DSO control flow integrity (Clang part).Evgeniy Stepanov2015-12-151-0/+1
| | | | | | | | | | | | | | Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
* Do not generate DW_TAG_imported_module for anonymous namespaces (even ↵Ekaterina Romanova2015-12-101-0/+3
| | | | | | | | | | nested) for all the platforms except PS4. For PS4, generate explicit import for anonymous namespaces and mark it by DW_AT_artificial attribute. Differential Revision: http://reviews.llvm.org/D12624 llvm-svn: 255281
* [ThinLTO] Option to invoke ThinLTO backend passes and importingTeresa Johnson2015-12-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds new option -fthinlto-index=<file> to invoke the LTO pipeline along with function importing via clang using the supplied function summary index file. This supports invoking the parallel ThinLTO backend processes in a distributed build environment via clang. Additionally, this causes the module linker to be invoked on the bitcode file being compiled to perform any necessary promotion and renaming of locals that are exported via the function summary index file. Add a couple tests that confirm we get expected errors when we try to use the new option on a file that isn't bitcode, or specify an invalid index file. The tests also confirm that we trigger the expected function import pass. Depends on D15024 Reviewers: joker.eph, dexonsmith Subscribers: joker.eph, davidxl, cfe-commits Differential Revision: http://reviews.llvm.org/D15025 llvm-svn: 254927
OpenPOWER on IntegriCloud