summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/BackendUtil.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* add the -mrecip driver flag and process its optionsSanjay Patel2015-05-221-0/+3
| | | | | | | | | | | | | | | This is the front-end counterpart to D8982 (LLVM r238051). The -mrecip option interface is based on maintaining compatibility with gcc: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627 https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289 ...while adding more functionality (allowing users to specify the number of refinement steps for each estimate type). Differential Revision: http://reviews.llvm.org/D8989 llvm-svn: 238055
* Remove the code that pulled soft float attributes out of the featureEric Christopher2015-05-121-1/+0
| | | | | | | strings and remove the setting of TargetOptions::UseSoftFloat to match the code change in llvm r237079. llvm-svn: 237080
* [SanitizerCoverage] Implement user-friendly -fsanitize-coverage= flags.Alexey Samsonov2015-05-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Possible coverage levels are: * -fsanitize-coverage=func - function-level coverage * -fsanitize-coverage=bb - basic-block-level coverage * -fsanitize-coverage=edge - edge-level coverage Extra features are: * -fsanitize-coverage=indirect-calls - coverage for indirect calls * -fsanitize-coverage=trace-bb - tracing for basic blocks * -fsanitize-coverage=trace-cmp - tracing for cmp instructions * -fsanitize-coverage=8bit-counters - frequency counters Levels and features can be combined in comma-separated list, and can be disabled by subsequent -fno-sanitize-coverage= flags, e.g.: -fsanitize-coverage=bb,trace-bb,8bit-counters -fno-sanitize-coverage=trace-bb is equivalient to: -fsanitize-coverage=bb,8bit-counters Original semantics of -fsanitize-coverage flag is preserved: * -fsanitize-coverage=0 disables the coverage * -fsanitize-coverage=1 is a synonym for -fsanitize-coverage=func * -fsanitize-coverage=2 is a synonym for -fsanitize-coverage=bb * -fsanitize-coverage=3 is a synonym for -fsanitize-coverage=edge * -fsanitize-coverage=4 is a synonym for -fsanitize-coverage=edge,indirect-calls Driver tries to diagnose invalid flag usage, in particular: * At most one level (func,bb,edge) must be specified. * "trace-bb" and "8bit-counters" features require some level to be specified. See test case for more examples. Test Plan: regression test suite Reviewers: kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9577 llvm-svn: 236790
* [SanitizerCoverage] Give clang-cc1 the power to precisly specify needed ↵Alexey Samsonov2015-05-071-2/+9
| | | | | | | | | | | | | | | | | | sanitizier coverage mode. Summary: The next step is to add user-friendly control over these options to driver via -fsanitize-coverage= option. Test Plan: regression test suite Reviewers: kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9545 llvm-svn: 236756
* Fix -fobjc-arc doesn't work with -save-tempsSteven Wu2015-05-021-2/+1
| | | | | | | | | | The underlying problem is that there is currently no way to run ObjCARCContract from llvm bitcode which is required by ObjC ARC. This fix the problem by always enable ObjCARCContract pass if optimization is enabled. The ObjCARC Contract pass has almost no overhead on code that is not using ARC. llvm-svn: 236372
* InstrProf: Support for setting profile output from command lineJustin Bogner2015-04-301-0/+1
| | | | | | | | | | | | | | | | This change is the third of 3 patches to add support for specifying the profile output from the command line via -fprofile-instr-generate=<path>, where the specified output path/file will be overridden by the LLVM_PROFILE_FILE environment variable. This patch adds the necessary support to the clang frontend, and adds a new test. The compiler-rt and llvm parts are r236055 and r236288, respectively. Patch by Teresa Johnson. Thanks! llvm-svn: 236289
* uselistorder: Remove dead includeDuncan P. N. Exon Smith2015-04-151-1/+0
| | | | | | Forgot to remove the include in r234970 llvm-svn: 234972
* uselistorder: -mllvm -preserve-ll-use-list-order => -emit-llvm-uselistsDuncan P. N. Exon Smith2015-04-151-1/+2
| | | | | | | | | Follow up to r234962, start respecting `-emit-llvm-uselists even for LLVM assembly. Note that the driver never passes this flag; this is just a interface convenience/consistency for those using `-cc1` directly. This required LLVM r234969 (and predecessors). llvm-svn: 234970
* uselistorder: -mllvm -preserve-bc-use-list-order => -emit-llvm-uselistsDuncan P. N. Exon Smith2015-04-151-1/+1
| | | | | | | | | | | | | | | Stop relying on `cl::opt` to pass along the driver's decision to preserve use-lists. Create a new `-cc1` option called `-emit-llvm-uselists` that does the right thing (when -emit-llvm-bc). Note that despite its generic name, it *doesn't* do the right thing when -emit-llvm (LLVM assembly) yet. I'll hook that up soon. This doesn't really change the behaviour of the driver. The default is still to preserve use-lists for `clang -emit-llvm` and `clang -save-temps`, and nothing else. But it stops relying on global state (and also is a nicer interface for hackers using `clang -cc1`). llvm-svn: 234962
* uselistorder: Update for LLVM API change in r234959Duncan P. N. Exon Smith2015-04-151-1/+3
| | | | | | | | Now that `addBitcodeWriterPass()` requires an explicit bit to preserve use-list order, send it in from `clang`. It looks like I'll be able to push this up to the `-cc1` options. llvm-svn: 234960
* Use raw_pwrite_stream in clang.Rafael Espindola2015-04-141-7/+9
| | | | | | This is a small improvement to -emit-pth and allows llvm to start requiring it. llvm-svn: 234897
* [Driver] Properly support -mglobal-merge using explicit options.Ahmed Bougacha2015-04-111-2/+0
| | | | | | | | Follow-up to r234666. With this, the -m[no-]global-merge options have the expected behavior. Previously, -mglobal-merge was ignored, and there was no way of enabling the optimization. llvm-svn: 234668
* Update for LLVM api changes.Rafael Espindola2015-04-091-9/+4
| | | | llvm-svn: 234536
* Clang follow-up to LLVM r232772Duncan P. N. Exon Smith2015-03-191-2/+0
| | | | | | -verify-di is dead! Long live -verify! llvm-svn: 232779
* Add fveclib option.Michael Zolotukhin2015-03-171-0/+8
| | | | | Review: http://reviews.llvm.org/D8097 llvm-svn: 232533
* GCOV: Expose the -coverage-exit-block-before-body flag in clang -cc1Justin Bogner2015-03-161-0/+1
| | | | | | | | | This exposes the optional exit block placement logic from r232438 as a clang -cc1 option. There is a test on the llvm side, but there isn't really a way to inspect the gcov options from clang to test it here as well. llvm-svn: 232439
* Try to fix the build after removing DataLayoutPassReid Kleckner2015-03-041-3/+0
| | | | llvm-svn: 231278
* Add -funique-section-names and -fno-unique-section-names options.Rafael Espindola2015-02-201-0/+1
| | | | | | | | | For now -funique-section-names is the default, so no change in default behavior. The total .o size in a build of llvm and clang goes from 241687775 to 230649031 bytes if -fno-unique-section-names is used. llvm-svn: 230031
* [PM] Fix #include order here that I forgot to update before changing it.Chandler Carruth2015-02-131-1/+1
| | | | llvm-svn: 229092
* [PM] Move away from the old llvm/PassManager.h header and its usingChandler Carruth2015-02-131-22/+22
| | | | | | | | | | | | declarations and just use the legacy namespace qualifier in this file and the permanent header name. The old wrapper header is going away to make LLVM's build more modular, and without updating Clang I can't easily start to add usage of the new pass manager to Clang. This should make it more clear in the code which set of types is doing what. llvm-svn: 229090
* Allow to specify multiple -fsanitize-blacklist= arguments.Alexey Samsonov2015-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow user to provide multiple blacklists by passing several -fsanitize-blacklist= options. These options now don't override default blacklist from Clang resource directory, which is always applied (which fixes PR22431). -fno-sanitize-blacklist option now disables all blacklists that were specified earlier in the command line (including the default one). This change depends on http://reviews.llvm.org/D7367. Test Plan: regression test suite Reviewers: timurrrr Subscribers: cfe-commits, kcc, pcc Differential Revision: http://reviews.llvm.org/D7368 llvm-svn: 228156
* [multiversion] Update Clang for the API change in LLVM r227731.Chandler Carruth2015-02-011-6/+9
| | | | | | | | | | | This moves all of the PassManager <-> Target communication to use the new pass manager's TargetIRAnalysis even with the old pass manager. See the LLVM commit for some of why things are moving in this direction, but the short version is that this will enable us to create per-function TargetTransformInfo objects that have correct subtarget information for that function. llvm-svn: 227732
* [PM] Update Clang for the new LLVM API in r227685 for managing theChandler Carruth2015-01-311-9/+11
| | | | | | TargetTransformInfo, and unify the code in a single place. llvm-svn: 227686
* Update for LLVM API change.Eric Christopher2015-01-261-3/+2
| | | | llvm-svn: 227114
* [PM] Update Clang to reflect the TLI API change in LLVM r226981.Chandler Carruth2015-01-241-8/+9
| | | | llvm-svn: 226982
* Replace size() calls on containers with empty() calls where appropriate. NFCAlexander Kornienko2015-01-231-1/+1
| | | | | | | | http://reviews.llvm.org/D7090 Patch by Gábor Horváth! llvm-svn: 226914
* [PM] Track an LLVM API update which separates the TargetLibraryInfoChandler Carruth2015-01-151-1/+2
| | | | | | | | | | object from the pass that provides access to it. We should probably refactor the createTLI code here in Clang in light of the new structure, but I wanted this patch to be a minimal one that just patches the behavior back together. llvm-svn: 226158
* [PM] Update for LLVM r226078 which moved TargetLibraryInfo to theChandler Carruth2015-01-151-1/+1
| | | | | | Analysis library. llvm-svn: 226079
* Revert "Insert random noops to increase security against ROP attacks (clang)"JF Bastien2015-01-141-1/+0
| | | | | | | This reverts commit: http://reviews.llvm.org/D3393 llvm-svn: 225947
* Insert random noops to increase security against ROP attacks (clang)JF Bastien2015-01-141-0/+1
| | | | | | | | | | | | | | | | | | | | A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks. Command line options: -noop-insertion // Enable noop insertion. -noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion) -max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions. In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future). -fdiversify This is the clang part of the patch. llvm part: D3392 http://reviews.llvm.org/D3393 Patch by Stephen Crane (@rinon) llvm-svn: 225910
* Update for move in llvm.Eric Christopher2015-01-141-1/+1
| | | | llvm-svn: 225892
* Driver: begin threading frontend support for SymbolRewriterSaleem Abdulrasool2015-01-091-0/+14
| | | | | | | | | | Allow blessed access to the symbol rewriter from the driver. Although the symbol rewriter could be invoked through tools like opt and llc, it would not accessible from the frontend. This allows us to read the rewrite map files in the frontend rather than the backend and enable symbol rewriting for actually performing the symbol interpositioning. llvm-svn: 225504
* Update for llvm front end change and use the TargetOptions structEric Christopher2014-12-181-0/+1
| | | | | | for ABI. llvm-svn: 224493
* InstrProf: Use LLVM's -instrprof pass for profilingJustin Bogner2014-12-081-0/+6
| | | | | | | | The logic for lowering profiling counters has been moved to an LLVM pass. Emit the intrinsics rather than duplicating the whole pass in clang. llvm-svn: 223683
* Introduce -fsanitize-coverage=N flagKostya Serebryany2014-11-111-0/+15
| | | | | | | | | | | | | | | | | | | Summary: This change makes the asan-coverge (formerly -mllvm -asan-coverge) accessible via a clang flag. Companion patch to LLVM is http://reviews.llvm.org/D6152 Test Plan: regression tests, chromium Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6153 llvm-svn: 221719
* [Sanitizer] Refactor sanitizer options in LangOptions.Alexey Samsonov2014-11-111-1/+1
| | | | | | | | | | | | | | | | | | Get rid of ugly SanitizerOptions class thrust into LangOptions: * Make SanitizeAddressFieldPadding a regular language option, and rely on default behavior to initialize/reset it. * Make SanitizerBlacklistFile a regular member LangOptions. * Introduce the helper class "SanitizerSet" to represent the set of enabled sanitizers and make it a member of LangOptions. It is exactly the entity we want to cache and modify in CodeGenFunction, for instance. We'd also be able to reuse SanitizerSet in CodeGenOptions for storing the set of recoverable sanitizers, and in the Driver to represent the set of sanitizers turned on/off by the commandline flags. No functionality change. llvm-svn: 221653
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-5/+5
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* Add a new -fmerge-functions -cc1 flag that enables function merging.Nick Lewycky2014-10-241-0/+1
| | | | llvm-svn: 220543
* Move -fsanitize-blacklist to LangOpts from CodeGenOpts. NFC.Alexey Samsonov2014-10-151-2/+2
| | | | | | | | After http://reviews.llvm.org/D5687 is submitted, we will need SanitizerBlacklist before the CodeGen phase, so make it a LangOpt (as it will actually affect ABI / class layout). llvm-svn: 219842
* CFE Knob for: Add a thread-model knob for lowering atomics on baremetal & ↵Jonathan Roelofs2014-10-031-0/+5
| | | | | | | | single threaded systems http://reviews.llvm.org/D4985 llvm-svn: 219027
* Update for llvm api change.Rafael Espindola2014-09-101-3/+3
| | | | llvm-svn: 217547
* Provide a BuryPointer for unique_ptrs.David Blaikie2014-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, it'd be nice if we could move to a case where all buried pointers were buried via unique_ptr to demonstrate that the program had finished with the value (that we could really have cleanly deallocated it) but instead chose to bury it. I think the main reason that's not possible right now is the various IntrusiveRefCntPtrs in the Frontend, sharing ownership for a variety of compiler bits (see the various similar "CompilerInstance::releaseAndLeak*" functions). I have yet to figure out their correct ownership semantics - but perhaps, even if the intrusiveness can be removed, the shared ownership may yet remain and that would lead to a non-unique burying as is there today. (though we could model that a little better - by passing in a shared_ptr, etc - rather than needing the two step that's currently used in those other releaseAndLeak* functions) This might be a bit more robust if BuryPointer took the boolean: BuryPointer(bool, unique_ptr<T>) and the choice to bury was made internally - that way, even when DisableFree was not set, the unique_ptr would still be null in the caller and there'd be no chance of accidentally having a different codepath where the value is used after burial in !DisableFree, but it becomes null only in DisableFree, etc... llvm-svn: 216742
* Convert MC command line flag for fatal assembler warnings into a properJoerg Sonnenberger2014-08-261-0/+1
| | | | | | flag. llvm-svn: 216472
* Refactor TLI creation. NFC.Rafael Espindola2014-08-211-7/+10
| | | | llvm-svn: 216198
* Update for LLVM API change.Eric Christopher2014-08-041-2/+4
| | | | llvm-svn: 214786
* Use -enable-global-merge option to match llvm r210639. <rdar://problem/17803206>Bob Wilson2014-07-261-1/+1
| | | | | | | | | llvm revision 210639 renamed the -global-merge backend option to -enable-global-merge. This change simply updates clang to match that. Patch by Steven Wu! llvm-svn: 213993
* [ASan] Completely remove sanitizer blacklist file from instrumentation pass.Alexey Samsonov2014-07-081-4/+1
| | | | | | | | | | | | | | | | | | | | All blacklisting logic is now moved to the frontend (Clang). If a function (or source file it is in) is blacklisted, it doesn't get sanitize_address attribute and is therefore not instrumented. If a global variable (or source file it is in) is blacklisted, it is reported to be blacklisted by the entry in llvm.asan.globals metadata, and is not modified by the instrumentation. The latter may lead to certain false positives - not all the globals created by Clang are described in llvm.asan.globals metadata (e.g, RTTI descriptors are not), so we may start reporting errors on them even if "module" they appear in is blacklisted. We assume it's fine to take such risk: 1) errors on these globals are rare and usually indicate wild memory access 2) we can lazily add descriptors for these globals into llvm.asan.globals lazily. llvm-svn: 212505
* Remove top-level Clang -fsanitize= flags for optional ASan features.Alexey Samsonov2014-06-131-7/+2
| | | | | | | | | | | | | Init-order and use-after-return modes can currently be enabled by runtime flags. use-after-scope mode is not really working at the moment. The only problem I see is that users won't be able to disable extra instrumentation for init-order and use-after-scope by a top-level Clang flag. But this instrumentation was implicitly enabled for quite a while and we didn't hear from users hurt by it. llvm-svn: 210924
* Remove unused variableAlexey Samsonov2014-06-021-2/+0
| | | | llvm-svn: 210041
* Remove sanitizer blacklist from ASan/TSan/MSan function passes.Alexey Samsonov2014-06-021-9/+5
| | | | | | | | | | | | | | | | | Instrumentation passes now use attributes address_safety/thread_safety/memory_safety which are added by Clang frontend. Clang parses the blacklist file and adds the attributes accordingly. Currently blacklist is still used in ASan module pass to disable instrumentation for certain global variables. We should fix this as well by collecting the set of globals we're going to instrument in Clang and passing it to ASan in metadata (as we already do for dynamically-initialized globals and init-order checking). This change also removes -tsan-blacklist and -msan-blacklist LLVM commandline flags in favor of -fsanitize-blacklist= Clang flag. llvm-svn: 210037
OpenPOWER on IntegriCloud