summaryrefslogtreecommitdiffstats
path: root/include/clang/Frontend/CodeGenOptions.def
Commit message (Collapse)AuthorAgeFilesLines
* New clang option -fno-plt which avoids the PLT and lazy binding while making ↵Sriraman Tallam2017-11-071-0/+2
| | | | | | | | external calls. Differential Revision: https://reviews.llvm.org/D39079 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317605 91177308-0d34-0410-b5e6-96231b3b80d8
* [CFI] Add CFI-icall pointer type generalizationVlad Tsyrklevich2017-10-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows generalizing pointers in type signatures used for cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag. This works by 1) emitting an additional generalized type signature metadata node for functions and 2) llvm.type.test()ing for the generalized type for translation units with the flag specified. This flag is incompatible with -fsanitize-cfi-cross-dso because it would require emitting twice as many type hashes which would increase artifact size. Reviewers: pcc, eugenis Reviewed By: pcc Subscribers: kcc Differential Revision: https://reviews.llvm.org/D39358 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317044 91177308-0d34-0410-b5e6-96231b3b80d8
* [Bitfield] Add an option to access bitfield in a fine-grained manner.Wei Mi2017-10-161-0/+1
| | | | | | | | | Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default. Differential revision: https://reviews.llvm.org/D36562 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315915 91177308-0d34-0410-b5e6-96231b3b80d8
* [DWARF] Allow forward declarations of a class template instantiationPaul Robinson2017-09-281-0/+4
| | | | | | | | | | to have child entries describing the template parameters. This will be on by default for SCE tuning. Differential Revision: https://reviews.llvm.org/D14358 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314444 91177308-0d34-0410-b5e6-96231b3b80d8
* IR: Represent -ggnu-pubnames with a flag on the DICompileUnit.Peter Collingbourne2017-09-121-0/+3
| | | | | | | | This allows the flag to be persisted through to LTO. Differential Revision: https://reviews.llvm.org/D37655 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313078 91177308-0d34-0410-b5e6-96231b3b80d8
* Minimal runtime for UBSan.Evgeniy Stepanov2017-08-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: An implementation of ubsan runtime library suitable for use in production. Minimal attack surface. * No stack traces. * Definitely no C++ demangling. * No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general. * as simple as possible Minimal CPU and RAM overhead. * Source locations unnecessary in the presence of (split) debug info. * Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at. * above two items save 3% binary size. When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt. Reviewers: pcc, kcc Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D36810 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312029 91177308-0d34-0410-b5e6-96231b3b80d8
* Add flag to request Clang is ABI-compatible with older versions of itselfRichard Smith2017-08-261-0/+4
| | | | | | | | | | | | | | | | | | | This patch adds a flag -fclang-abi-compat that can be used to request that Clang attempts to be ABI-compatible with some older version of itself. This is provided on a best-effort basis; right now, this can be used to undo the ABI change in r310401, reverting Clang to its prior C++ ABI for pass/return by value of class types affected by that change, and to undo the ABI change in r262688, reverting Clang to using integer registers rather than SSE registers for passing <1 x long long> vectors. The intent is that we will maintain this backwards compatibility path as we make ABI-breaking fixes in future. The reversion to the old behavior for r310401 is also applied to the PS4 target since that change is not part of its platform ABI (which is essentially to do whatever Clang 3.2 did). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311823 91177308-0d34-0410-b5e6-96231b3b80d8
* Expose -mllvm -accurate-sample-profile to clang.Dehao Chen2017-08-241-0/+1
| | | | | | | | | | | | | | Summary: With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size by 20% Reviewers: davidxl, rsmith Reviewed By: davidxl, rsmith Subscribers: mehdi_amini, eraman, sanjoy, cfe-commits Differential Revision: https://reviews.llvm.org/D37091 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311707 91177308-0d34-0410-b5e6-96231b3b80d8
* [SanitizerCoverage] Add stack depth tracing instrumentation.Matt Morehouse2017-08-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Augment SanitizerCoverage to insert maximum stack depth tracing for use by libFuzzer. The new instrumentation is enabled by the flag -fsanitize-coverage=stack-depth and is compatible with the existing trace-pc-guard coverage. The user must also declare the following global variable in their code: thread_local uintptr_t __sancov_lowest_stack https://bugs.llvm.org/show_bug.cgi?id=33857 Reviewers: vitalybuka, kcc Reviewed By: vitalybuka Subscribers: kubamracek, hiraditya, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D36839 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311186 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips] Revert r309942 & r309940Simon Dardis2017-08-031-2/+0
| | | | | | | | | This reverts commit r309942 & commit r309940. A revert was requested following post commit review. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309978 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips] Implement -muninit-const-in-rodataSimon Dardis2017-08-031-0/+2
| | | | | | | | | | | | This option when combined with -mgpopt and -membedded-data places all uninitialized constant variables in the read-only section. Reviewers: atanasyan, nitesh.jain Differential Revision: https://reviews.llvm.org/D35917 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309940 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] clang flags pumbing for -fsanitize-coverage=pc-tableKostya Serebryany2017-07-281-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309338 91177308-0d34-0410-b5e6-96231b3b80d8
* Un-revert "[Driver] Add -fdiagnostics-hotness-threshold"Brian Gesiak2017-07-011-0/+4
| | | | | | | | | | Summary: Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the documentation to fix an error -- I had used the wrong syntax for a link. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306948 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Driver] Add -fdiagnostics-hotness-threshold"Brian Gesiak2017-07-011-4/+0
| | | | | | | | | Summary: The commit caused a documentation breakage. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306946 91177308-0d34-0410-b5e6-96231b3b80d8
* [Driver] Add -fdiagnostics-hotness-thresholdBrian Gesiak2017-07-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Depends on https://reviews.llvm.org/D34867. Add a Clang frontend option to enable optimization remark hotness thresholds, which were added to LLVM in https://reviews.llvm.org/D34867. This prevents diagnostics that do not meet a minimum hotness threshold from being output. When generating optimization remarks for large codebases with a ton of cold code paths, this option can be used to limit the optimization remark output at a reasonable size. Discussion of this change can be read here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html Reviewers: anemet, davidxl, hfinkel Reviewed By: anemet Subscribers: fhahn, cfe-commits Differential Revision: https://reviews.llvm.org/D34868 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306945 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove Clang support for '-fvectorize-slp-aggressive' which used LLVM'sChandler Carruth2017-06-301-1/+0
| | | | | | | | | | | | | | | | | | basic block vectorizer. This vectorizer has had no known users for many, many years and is completely surpassed by the normal '-fvectorize-slp'-controlled SLP vectorizer in LLVM. Hal proposed this back in 2014 to no objections: http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html While this patch completely removes the flag, Joerg is working on a patch that will add it back in a way that warns users and ignores the flag in a clear and well factored way (so that we can keep doing this going forward). Differential Revision: https://reviews.llvm.org/D34846 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306786 91177308-0d34-0410-b5e6-96231b3b80d8
* [NewPM] Add Clang cc1 flag -fdebug-pass-manager for printing debug information.Tim Shen2017-06-291-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D34790 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306757 91177308-0d34-0410-b5e6-96231b3b80d8
* Represent debug information compression type fullySaleem Abdulrasool2017-06-091-1/+2
| | | | | | | | | | | This is tied with the LLVM side of the change to expose the debug information compression types to clang. We now track the compression type as an enumeration rather than a boolean. We still use the same value (GNU) that we did previously. This is in preparation to support passing down the compression type and switch it based on the command line. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305039 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] one more flavor of coverage: ↵Kostya Serebryany2017-06-081-0/+1
| | | | | | -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. Reapplying revisions 304630, 304631, 304632, 304673, see PR33308 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305026 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[sanitizer-coverage] one more flavor of coverage: ↵Renato Golin2017-06-051-1/+0
| | | | | | | | -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)" This reverts commit r304631, as it broke ARM/AArch64 bots for 2 days. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304697 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] one more flavor of coverage: ↵Kostya Serebryany2017-06-031-0/+1
| | | | | | -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304631 91177308-0d34-0410-b5e6-96231b3b80d8
* IRGen: Add optnone attribute on function during O0Mehdi Amini2017-05-291-0/+1
| | | | | | | | | | | Amongst other, this will help LTO to correctly handle/honor files compiled with O0, helping debugging failures. It also seems in line with how we handle other options, like how -fnoinline adds the appropriate attribute as well. Differential Revision: https://reviews.llvm.org/D28404 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304127 91177308-0d34-0410-b5e6-96231b3b80d8
* [asan] A clang flag to enable ELF globals-gc.Evgeniy Stepanov2017-05-091-0/+2
| | | | | | | | | | | | This feature is subtly broken when the linker is gold 2.26 or earlier. See the following bug for details: https://sourceware.org/bugzilla/show_bug.cgi?id=19002 Since the decision needs to be made at compilation time, we can not test the linker version. The flag is off by default on ELF targets, and on otherwise. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302591 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a ↵Kostya Serebryany2017-05-051-0/+1
| | | | | | hidden -mllvm flag. clang part. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302320 91177308-0d34-0410-b5e6-96231b3b80d8
* Move Split DWARF handling to an MC option/command line argument rather than ↵David Blaikie2017-04-211-0/+1
| | | | | | | | | | | | | | | | | | | using metadata Since Split DWARF needs to name the actual .dwo file that is generated, it can't be known at the time the llvm::Module is produced as it may be merged with other Modules before the object is generated and that object may be generated with any name. By passing the Split DWARF file name when LLVM is producing object code the .dwo file name in the object file can match correctly. The support for Split DWARF for implicit modules remains the same - using metadata to store the dwo name and dwo id so that potentially multiple skeleton CUs referring to different dwo files can be generated from one llvm::Module. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301063 91177308-0d34-0410-b5e6-96231b3b80d8
* Preserve vec3 type.Jin-Gu Kang2017-04-041-0/+3
| | | | | | | | | | | | | | Summary: Preserve vec3 type with CodeGen option. Reviewers: Anastasia, bruno Reviewed By: Anastasia Subscribers: bruno, ahatanak, cfe-commits Differential Revision: https://reviews.llvm.org/D30810 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299445 91177308-0d34-0410-b5e6-96231b3b80d8
* Use FPContractModeKind universallyAdam Nemet2017-03-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. --- This is a recommit of r299027 with an adjustment to the test CodeGenCUDA/fp-contract.cu. The test assumed that even though -ffp-contract=on is passed FE-based folding of FMA won't happen. This is obviously wrong since the user is asking for this explicitly with the option. CUDA is different that -ffp-contract=fast is on by default. The test used to "work" because contract=fast and contract=on were maintained separately and we didn't fold in the FE because contract=fast was on due to the target-default. This patch consolidates the contract=on/fast/off state into a ternary state hence the change in behavior. --- Differential Revision: https://reviews.llvm.org/D31167 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299033 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Use FPContractModeKind universally"Adam Nemet2017-03-291-0/+2
| | | | | | | | This reverts commit r299027. It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299029 91177308-0d34-0410-b5e6-96231b3b80d8
* Use FPContractModeKind universallyAdam Nemet2017-03-291-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31167 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299027 91177308-0d34-0410-b5e6-96231b3b80d8
* [DebugInfo] Added support to Clang FE for generating debug info for ↵Amjad Aboud2017-02-091-0/+3
| | | | | | | | | | | preprocessor macros. Added "-fdebug-macro" flag (and "-fno-debug-macro" flag) to enable (and to disable) emitting macro debug info. Added CC1 "-debug-info-macro" flag that enables emitting macro debug info. Differential Revision: https://reviews.llvm.org/D16135 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294637 91177308-0d34-0410-b5e6-96231b3b80d8
* [X86] Teach Clang about -mfentry flagNirav Dave2017-01-311-0/+1
| | | | | | | | | | | | Replace mcount calls with calls to fentry. Reviewers: hfinkel, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28001 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293649 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -fdebug-info-for-profiling to emit more debug info for sample pgo ↵Dehao Chen2017-01-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | profile collection Summary: SamplePGO uses profile with debug info to collect profile. Unlike the traditional debugging purpose, sample pgo needs more accurate debug info to represent the profile. We add -femit-accurate-debug-info for this purpose. It can be combined with all debugging modes (-g, -gmlt, etc). It makes sure that the following pieces of info is always emitted: * start line of all subprograms * linkage name of all subprograms * standalone subprograms (functions that has neither inlined nor been inlined) The impact on speccpu2006 binary size (size increase comparing with -g0 binary, also includes data for -g binary, which does not change with this patch): -gmlt(orig) -gmlt(patched) -g 433.milc 4.68% 5.40% 19.73% 444.namd 8.45% 8.93% 45.99% 447.dealII 97.43% 115.21% 374.89% 450.soplex 27.75% 31.88% 126.04% 453.povray 21.81% 26.16% 92.03% 470.lbm 0.60% 0.67% 1.96% 482.sphinx3 5.77% 6.47% 26.17% 400.perlbench 17.81% 19.43% 73.08% 401.bzip2 3.73% 3.92% 12.18% 403.gcc 31.75% 34.48% 122.75% 429.mcf 0.78% 0.88% 3.89% 445.gobmk 6.08% 7.92% 42.27% 456.hmmer 10.36% 11.25% 35.23% 458.sjeng 5.08% 5.42% 14.36% 462.libquantum 1.71% 1.96% 6.36% 464.h264ref 15.61% 16.56% 43.92% 471.omnetpp 11.93% 15.84% 60.09% 473.astar 3.11% 3.69% 14.18% 483.xalancbmk 56.29% 81.63% 353.22% geomean 15.60% 18.30% 57.81% Debug info size change for -gmlt binary with this patch: 433.milc 13.46% 444.namd 5.35% 447.dealII 18.21% 450.soplex 14.68% 453.povray 19.65% 470.lbm 6.03% 482.sphinx3 11.21% 400.perlbench 8.91% 401.bzip2 4.41% 403.gcc 8.56% 429.mcf 8.24% 445.gobmk 29.47% 456.hmmer 8.19% 458.sjeng 6.05% 462.libquantum 11.23% 464.h264ref 5.93% 471.omnetpp 31.89% 473.astar 16.20% 483.xalancbmk 44.62% geomean 16.83% Reviewers: davidxl, andreadb, rob.lougher, dblaikie, echristo Reviewed By: dblaikie, echristo Subscribers: hfinkel, rob.lougher, andreadb, gbedwell, cfe-commits, probinson, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D25435 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292458 91177308-0d34-0410-b5e6-96231b3b80d8
* Move vtable type metadata emission behind a cc1-level flag.Peter Collingbourne2017-01-181-0/+2
| | | | | | | | | | | | | In ThinLTO mode, type metadata will require the module to be written as a multi-module bitcode file, which is currently incompatible with the Darwin linker. It is also useful to be able to enable or disable multi-module bitcode for testing purposes. This introduces a cc1-level flag, -f{,no-}lto-unit, which is used by the driver to enable multi-module bitcode on all but Darwin+ThinLTO, and can also be used to enable/disable the feature manually. Differential Revision: https://reviews.llvm.org/D28877 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292448 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a cc1 option to force disabling lifetime-markers emission from clangMehdi Amini2017-01-061-0/+1
| | | | | | | | Summary: This intended as a debugging/development flag only. Differential Revision: https://reviews.llvm.org/D28385 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291300 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -f[no-]strict-return flag that can be used to avoid undefined behaviourAlex Lorenz2017-01-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | in non-void functions that fall off at the end without returning a value when compiling C++. Clang uses the new compiler flag to determine when it should treat control flow paths that fall off the end of a non-void function as unreachable. If -fno-strict-return is on, the code generator emits the ureachable and trap IR only when the function returns either a record type with a non-trivial destructor or another non-trivially copyable type. The primary goal of this flag is to avoid treating falling off the end of a non-void function as undefined behaviour. The burden of undefined behaviour is placed on the caller instead: if the caller ignores the returned value then the undefined behaviour is avoided. This kind of behaviour is useful in several cases, e.g. when compiling C code in C++ mode. rdar://13102603 Differential Revision: https://reviews.llvm.org/D27163 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290960 91177308-0d34-0410-b5e6-96231b3b80d8
* [PM] Introduce options to enable the (still experimental) new passChandler Carruth2016-12-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | manager, and a code path to use it. The option is actually a top-level option but does contain 'experimental' in the name. This is the compromise suggested by Richard in discussions. We expect this option will be around long enough and have enough users towards the end that it merits not being relegated to CC1, but it still needs to be clear that this option will go away at some point. The backend code is a fresh codepath dedicated to handling the flow with the new pass manager. This was also Richard's suggested code structuring to essentially leave a clean path for development rather than carrying complexity or idiosyncracies of how we do things just to share code with the parts of this in common with the legacy pass manager. And it turns out, not much is really in common even though we use the legacy pass manager for codegen at this point. I've switched a couple of tests to run with the new pass manager, and they appear to work. There are still plenty of bugs that need squashing (just with basic experiments I've found two already!) but they aren't in this code, and the whole point is to expose the necessary hooks to start experimenting with the pass manager in more realistic scenarios. That said, I want to *strongly caution* anyone itching to play with this: it is still *very shaky*. Several large components have not yet been shaken down. For example I have bugs in both the always inliner and inliner that I have already spotted and will be fixing independently. Still, this is a fun milestone. =D One thing not in this patch (but that might be very reasonable to add) is some level of support for raw textual pass pipelines such as what Sean had a patch for some time ago. I'm mostly interested in the more traditional flow of getting the IR out of Clang and then running it through opt, but I can see other use cases so someone may want to add it. And of course, *many* features are not yet supported! - O1 is currently more like O2 - None of the sanitizers are wired up - ObjC ARC optimizer isn't wired up - ... So plenty of stuff still lef to do! Differential Revision: https://reviews.llvm.org/D28077 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290450 91177308-0d34-0410-b5e6-96231b3b80d8
* Cleanup the handling of noinline function attributes, -fno-inline,Chandler Carruth2016-12-231-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290398 91177308-0d34-0410-b5e6-96231b3b80d8
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290392 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r285664, cxx-abi-dev chose to go in a different direction for the ABI ↵Richard Smith2016-12-011-1/+0
| | | | | | here. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288304 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement ABI proposal for throwing noexcept function pointers, per discussionRichard Smith2016-11-011-0/+1
| | | | | | | | | on cxx-abi-dev (thread starting 2016-10-11). This is currently hidden behind a cc1-only -m flag, pending discussion of how best to deal with language changes that require use of new symbols from the ABI library. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285664 91177308-0d34-0410-b5e6-96231b3b80d8
* New clang option -mpie-copy-relocations to use copy relocations for PIE builds.Sriraman Tallam2016-10-191-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D19996 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284638 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] add yet another flavour of coverage instrumentation: ↵Kostya Serebryany2016-09-141-0/+2
| | | | | | trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. Clang part git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281432 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply r281276 with passing -emit-llvm in one of the testsAdam Nemet2016-09-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Original commit message: Add -fdiagnostics-show-hotness Summary: I've recently added the ability for optimization remarks to include the hotness of the corresponding code region. This uses PGO and allows filtering of the optimization remarks by relevance. The idea was first discussed here: http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334 The general goal is to produce a YAML file with the remarks. Then, an external tool could dynamically filter these by hotness and perhaps by other things. That said it makes sense to also expose this at the more basic level where we just include the hotness info with each optimization remark. For example, in D22694, the clang flag was pretty useful to measure the overhead of the additional analyses required to include hotness. (Without the flag we don't even run the analyses.) For the record, Hal has already expressed support for the idea of this patch on IRC. Differential Revision: https://reviews.llvm.org/D23284 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281293 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Add -fdiagnostics-show-hotness"Adam Nemet2016-09-131-3/+0
| | | | | | | | This reverts commit r281276. Many bots are failing. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281279 91177308-0d34-0410-b5e6-96231b3b80d8
* Add -fdiagnostics-show-hotnessAdam Nemet2016-09-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I've recently added the ability for optimization remarks to include the hotness of the corresponding code region. This uses PGO and allows filtering of the optimization remarks by relevance. The idea was first discussed here: http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334 The general goal is to produce a YAML file with the remarks. Then, an external tool could dynamically filter these by hotness and perhaps by other things. That said it makes sense to also expose this at the more basic level where we just include the hotness info with each optimization remark. For example, in D22694, the clang flag was pretty useful to measure the overhead of the additional analyses required to include hotness. (Without the flag we don't even run the analyses.) For the record, Hal has already expressed support for the idea of this patch on IRC. Differential Revision: https://reviews.llvm.org/D23284 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281276 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a long comment lineAdam Nemet2016-09-121-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281275 91177308-0d34-0410-b5e6-96231b3b80d8
* This adds new options -fdenormal-fp-math and passes through option -ffast-mathSjoerd Meijer2016-08-301-0/+1
| | | | | | | | | | | to CC1, which are translated to function attributes and can e.g. be mapped on build attributes FP_exceptions and FP_denormal. Setting these build attributes allows better selection of floating point libraries. Differential Revision: https://reviews.llvm.org/D23840 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280064 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer-coverage] add two more modes of instrumentation: trace-div and ↵Kostya Serebryany2016-08-301-0/+4
| | | | | | trace-gep, mostly usaful for value-profile-based fuzzing; clang part git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280044 91177308-0d34-0410-b5e6-96231b3b80d8
* DebugInfo: Add flag to CU to disable emission of inline debug info into the ↵David Blaikie2016-08-241-0/+3
| | | | | | | | | | skeleton CU In cases where .dwo/.dwp files are guaranteed to be available, skipping the extra online (in the .o file) inline info can save a substantial amount of space - see the original r221306 for more details there. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@279651 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenCL] Handle -cl-fp32-correctly-rounded-divide-sqrtYaxun Liu2016-08-091-0/+1
| | | | | | | | Let the driver pass the option to frontend. Do not set precision metadata for division instructions when this option is set. Set function attribute "correctly-rounded-divide-sqrt-fp-math" based on this option. Differential Revision: https://reviews.llvm.org/D22940 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278155 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 12:45:54 +0000