summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/Inputs
Commit message (Collapse)AuthorAgeFilesLines
* [DebugInfo] Support DWARF v5 source code embedding extensionScott Linder2018-02-261-0/+1
| | | | | | | | | | | | | In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. This vendor extension to DWARF v5 allows source text to be embedded directly in the line tables of the debug line section. Add new flag (-g[no-]embed-source) to Driver and CC1 which indicates that source should be passed through to LLVM during CodeGen. Differential Revision: https://reviews.llvm.org/D42766 llvm-svn: 326102
* [ThinLTO] Allow indexing to request backend to ignore the moduleVitaly Buka2018-02-161-0/+0
| | | | | | | | | | | | | | | | | | Summary: Gold plugin does not add pass to ThinLTO modules without useful symbols. In this case ThinLTO can't create corresponding index file and some features, like CFI, cannot be processes by backed correctly without index. Given that we don't need the backed output we can request it to avoid processing the module. This is implemented by this patch using new "SkipModuleByDistributedBackend" flag. Reviewers: pcc, tejohnson Subscribers: mehdi_amini, inglorion, eraman, cfe-commits Differential Revision: https://reviews.llvm.org/D42995 llvm-svn: 325411
* Allow specifying sanitizers in blacklistsVlad Tsyrklevich2017-09-255-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the follow-up patch to D37924. This change refactors clang to use the the newly added section headers in SpecialCaseList to specify which sanitizers blacklists entries should apply to, like so: [cfi-vcall] fun:*bad_vcall* [cfi-derived-cast|cfi-unrelated-cast] fun:*bad_cast* The SanitizerSpecialCaseList class has been added to allow querying by SanitizerMask, and SanitizerBlacklist and its downstream users have been updated to provide that information. Old blacklists not using sections will continue to function identically since the blacklist entries will be placed into a '[*]' section by default matching against all sanitizers. Reviewers: pcc, kcc, eugenis, vsk Reviewed By: eugenis Subscribers: dberris, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D37925 llvm-svn: 314171
* Revert r307445 as it breaks on certain platforms.Dehao Chen2017-07-071-7/+2
| | | | llvm-svn: 307449
* Add sample PGO integration test to cover profile annotation and inlining.Dehao Chen2017-07-071-2/+7
| | | | | | | | | | | | | | Summary: The patch makes the integration test cover major sample PGO components. Reviewers: davidxl Reviewed By: davidxl Subscribers: sanjoy, cfe-commits Differential Revision: https://reviews.llvm.org/D34725 llvm-svn: 307445
* Apply summary-based dead stripping to regular LTO modules with summaries.Peter Collingbourne2017-06-151-0/+9
| | | | | | | | | | | | | | | If a regular LTO module has a summary index, then instead of linking it into the combined regular LTO module right away, add it to the combined summary index and associate it with a special module that represents the combined regular LTO module. Any such modules are linked during LTO::run(), at which time we use the results of summary-based dead stripping to control whether to link prevailing symbols. Differential Revision: https://reviews.llvm.org/D33922 llvm-svn: 305482
* Update the SamplePGO test to verify that unroll/icp is not invoked in ↵Dehao Chen2017-03-231-0/+2
| | | | | | | | | | | | | | | | thinlto compile phase. Summary: This is the test added for https://reviews.llvm.org/D31217 Reviewers: tejohnson, mehdi_amini Reviewed By: tejohnson Subscribers: cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D31219 llvm-svn: 298647
* Clang change: Do not inline hot callsites for samplepgo in thinlto compile ↵Dehao Chen2017-03-211-0/+2
| | | | | | | | | | | | | | | | | | phase. Summary: Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to make sure the IR at the 2nd phase matches the hot part in pro file, thus we do not want to inline hot callsites in the first phase. Reviewers: tejohnson, eraman Reviewed By: tejohnson Subscribers: mehdi_amini, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D31202 llvm-svn: 298429
* Move test include file from include/ to Inputs/Richard Trieu2017-02-111-0/+12
| | | | | | | The Inputs/ directory is the recommended location for extra files for test cases. No functional change. llvm-svn: 294815
* [DebugInfo] Added support for Checksum debug info feature.Amjad Aboud2016-12-251-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D27641 llvm-svn: 290515
* Add an option to save the backend-produced YAML optimization record to a fileHal Finkel2016-10-111-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization diagnostics but in machine-consumable form, into an output file. This can be enabled when using opt (see r282539), and this change enables it when using clang. The idea is that other tools will be able to consume these files, and perhaps in combination with the original source code, produce various kinds of optimization reports for users (and for compiler developers). We now have at-least two tools that can consume these files: * tools/llvm-opt-report * utils/opt-viewer Using the flag -fsave-optimization-record will cause the YAML file to be generated; the file name will be based on the output file name (if we're using -c or -S and have an output name), or the input file name. When we're using CUDA, or some other offloading mechanism, separate files are generated for each backend target. The output file name can be specified by the user using -foptimization-record-file=filename. Differential Revision: https://reviews.llvm.org/D25225 llvm-svn: 283834
* CodeGen: Replace test/CodeGen/thinlto_backend.c with a functional test.Peter Collingbourne2016-06-221-0/+6
| | | | | | | | | | | This new test tests that functions are capable of being imported, rather than that the import pass is run. This new test is compatible with the approach being developed in D20268 which runs the importer on its own rather than in a pass. Differential Revision: http://reviews.llvm.org/D21542 llvm-svn: 273347
* Invoke PruneEH pass before Sample Profile pass.Dehao Chen2016-06-211-0/+2
| | | | | | | | | | | | Summary: We need to call PruneEH pass before AutoFDO pass so that some EH-related calls can get inlined in Sample Profile pass. Reviewers: davidxl, dnovillo Subscribers: junbuml, llvm-commits Differential Revision: http://reviews.llvm.org/D21197 llvm-svn: 273298
* [PGO] Change profile use cc1 option to handle IR level profilesRong Xu2016-03-022-0/+2
| | | | | | | | | | | | | | | | | | 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
* test: change argumentSaleem Abdulrasool2015-10-121-1/+1
| | | | | | | This failed on AArch64 due to the type mismatch using int instead of __builtin_va_list. llvm-svn: 250112
* test: Give instrumentation based profiling tests their own directoryJustin Bogner2014-03-112-177/+0
| | | | | | | | These tests are logically related, but they're spread about several different CodeGen directories. Consolidate them in one place to make them easier to manage. llvm-svn: 203541
* PGO: rename profile data files from .pgodata to .profdata.Bob Wilson2014-03-062-0/+0
| | | | | | | These tests were added before we had settled on using a .profdata extension for the profile data files. Renaming them now for consistency. llvm-svn: 203166
* PGO: Use the main file name to help distinguish functions with local linkage.Bob Wilson2014-03-061-0/+4
| | | | | | | | | | | | In addition, for all functions, use the name from the llvm::Function to identify the function in the profile data. Compute that "function name", including the file name for local functions, once when assigning the PGO counters and store it in the CodeGenPGO class. Move the code to add InlineHint and Cold attributes out of StartFunction(), because the "function name" string isn't available at that point. llvm-svn: 203075
* Add a testcase for r202437.Bob Wilson2014-02-281-0/+6
| | | | llvm-svn: 202468
* Change PGO instrumentation to compute counts in a separate AST traversal.Bob Wilson2014-02-171-36/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we made one traversal of the AST prior to codegen to assign counters to the ASTs and then propagated the count values during codegen. This patch now adds a separate AST traversal prior to codegen for the -fprofile-instr-use option to propagate the count values. The counts are then saved in a map from which they can be retrieved during codegen. This new approach has several advantages: 1. It gets rid of a lot of extra PGO-related code that had previously been added to codegen. 2. It fixes a serious bug. My original implementation (which was mailed to the list but never committed) used 3 counters for every loop. Justin improved it to move 2 of those counters into the less-frequently executed breaks and continues, but that turned out to produce wrong count values in some cases. The solution requires visiting a loop body before the condition so that the count for the condition properly includes the break and continue counts. Changing codegen to visit a loop body first would be a fairly invasive change, but with a separate AST traversal, it is easy to control the order of traversal. I've added a testcase (provided by Justin) to make sure this works correctly. 3. It improves the instrumentation overhead, reducing the number of counters for a loop from 3 to 1. We no longer need dedicated counters for breaks and continues, since we can just use the propagated count values when visiting breaks and continues. To make this work, I needed to make a change to the way we count case statements, going back to my original approach of not including the fall-through in the counter values. This was necessary because there isn't always an AST node that can be used to record the fall-through count. Now case statements are handled the same as default statements, with the fall-through paths branching over the counter increments. While I was at it, I also went back to using this approach for do-loops -- omitting the fall-through count into the loop body simplifies some of the calculations and make them behave the same as other loops. Whenever we start using this instrumentation for coverage, we'll need to add the fall-through counts into the counter values. llvm-svn: 201528
* PGO: fix a bug in parsing pgo data.Manman Ren2014-02-151-0/+3
| | | | | | | | When a function has a single counter, we will offset the pointer by 1 when parsing the next function. If a function has multiple counters, we are okay after skipping rest of the counters. llvm-svn: 201456
* PGO: instrumentation based profiling sets function attributes.Manman Ren2014-02-051-0/+39
| | | | | | | | | | | | | | | We collect a maximal function count among all functions in the pgo data file. For functions that are hot, we set its InlineHint attribute. For functions that are cold, we set its Cold attribute. We currently treat functions with >= 30% of the maximal function count as hot and functions with <= 1% of the maximal function count are treated as cold. These two numbers are from preliminary tuning on SPEC. This commit should not affect non-PGO builds and should boost performance on instrumentation based PGO. llvm-svn: 200874
* CodeGen: Fix tracking of PGO counters for the logical or operatorJustin Bogner2014-01-231-0/+12
| | | | | | | This adds tests for both logical or and for logical and, which was already correct. llvm-svn: 199865
* CodeGen: Initial instrumentation based PGO implementationJustin Bogner2014-01-061-0/+127
| | | | llvm-svn: 198640
* Add testcase for r148375!Nick Lewycky2012-01-181-0/+9
llvm-svn: 148378
OpenPOWER on IntegriCloud