summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/LLVMContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* allow custom OptBisect classes set to LLVMContextFedor Sergeev2018-04-051-1/+5
| | | | | | | | | | | | | | | | | | | | | This patch introduces a way to set custom OptPassGate instances to LLVMContext. A new instance field OptBisector and a new method setOptBisect() are added to the LLVMContext classes. These changes allow to set a custom OptBisect class that can make its own decisions on skipping optional passes. Another important feature of this change is ability to set different instances of OptPassGate to different LLVMContexts. So the different contexts can be used independently in several compiling threads of one process. One unit test is added. Patch by Yevgeny Rouban. Reviewers: andrew.w.kaylor, fedor.sergeev, vsk, dberlin, Eugene.Zelenko, reames, skatkov Reviewed By: andrew.w.kaylor, fedor.sergeev Differential Revision: https://reviews.llvm.org/D44464 llvm-svn: 329267
* [NFC] OptPassGate extracted from OptBisectFedor Sergeev2018-03-271-2/+2
| | | | | | | | | | | | | | | Summary: This is an NFC refactoring of the OptBisect class to split it into an optional pass gate interface used by LLVMContext and the Optional Pass Bisector (OptBisect) used for debugging of optional passes. This refactoring is needed for D44464, which introduces setOptPassGate() method to allow implementations other than OptBisect. Patch by Yevgeny Rouban. Reviewers: andrew.w.kaylor, fedor.sergeev, vsk, dberlin, Eugene.Zelenko, reames, skatkov Reviewed By: fedor.sergeev Differential Revision: https://reviews.llvm.org/D44821 llvm-svn: 328637
* Irreducible loop metadata for more accurate block frequency under PGO.Hiroshi Yamauchi2017-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Currently the block frequency analysis is an approximation for irreducible loops. The new irreducible loop metadata is used to annotate the irreducible loop headers with their header weights based on the PGO profile (currently this is approximated to be evenly weighted) and to help improve the accuracy of the block frequency analysis for irreducible loops. This patch is a basic support for this. Reviewers: davidxl Reviewed By: davidxl Subscribers: mehdi_amini, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D39028 llvm-svn: 317278
* Add !callees metadataMatthew Simpson2017-10-161-0/+1
| | | | | | | | | This patch adds a new kind of metadata that indicates the possible callees of indirect calls. Differential Revision: https://reviews.llvm.org/D37354 llvm-svn: 315944
* [OptRemark] Move YAML writing to IRAdam Nemet2017-10-041-0/+8
| | | | | | | | | | | | Before the patch this was in Analysis. Moving it to IR and making it implicit part of LLVMContext::diagnose allows the full opt-remark facility to be used outside passes e.g. the pass manager. Jessica is planning to use this to report function size after each pass. The same could be used for time reports. Tested with BUILD_SHARED_LIBS=On. llvm-svn: 314909
* Move verbosity check for remarks to the diag handlerAdam Nemet2017-10-041-1/+5
| | | | | | | | Test needs some slight adjustment because we no longer check the existence of BFI but rather that the actual hotness is set on the remark. If entry_count is not set getBlockProfileCount returns None. llvm-svn: 314874
* This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya2017-09-151-12/+26
| | | | | | | | | | | It enables OptimizationRemarkEmitter::allowExtraAnalysis and MachineOptimizationRemarkEmitter::allowExtraAnalysis to return true not only for -fsave-optimization-record but when specific remarks are requested with command line options. The diagnostic handler used to be callback now this patch adds a class DiagnosticHandler. It has virtual method to provide custom diagnostic handler and methods to control which particular remarks are enabled. However LLVM-C API users can still provide callback function for diagnostic handler. llvm-svn: 313390
* This reverts r313381Vivek Pandya2017-09-151-26/+12
| | | | llvm-svn: 313387
* This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 Vivek Pandya2017-09-151-12/+26
| | | | | | | | | | | It enables OptimizationRemarkEmitter::allowExtraAnalysis and MachineOptimizationRemarkEmitter::allowExtraAnalysis to return true not only for -fsave-optimization-record but when specific remarks are requested with command line options. The diagnostic handler used to be callback now this patch adds a class DiagnosticHandler. It has virtual method to provide custom diagnostic handler and methods to control which particular remarks are enabled. However LLVM-C API users can still provide callback function for diagnostic handler. llvm-svn: 313382
* Fix unused variable warningsKonstantin Zhuravlyov2017-07-121-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D35280 llvm-svn: 307740
* Enhance synchscope representationKonstantin Zhuravlyov2017-07-111-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
* [ORE] Add diagnostics hotness thresholdBrian Gesiak2017-06-301-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: Add an option to prevent 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: qcolombet, javed.absar, fhahn, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D34867 llvm-svn: 306912
* [ORE] Remove old "diagnostic hotness" spellingBrian Gesiak2017-06-301-7/+0
| | | | | | | | | | | | | | | | | | | Summary: Depends on https://reviews.llvm.org/D34865. With the Clang uses of the old spelling having been removed in https://reviews.llvm.org/D34865, get rid of the old "diagnostic hotness" spellings in favor of the new "diagnostics hotness". Reviewers: anemet, davidxl Reviewed By: anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34866 llvm-svn: 306866
* [ORE] Unify spelling as "diagnostics hotness"Brian Gesiak2017-06-301-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: To enable profile hotness information in diagnostics output, Clang takes the option `-fdiagnostics-show-hotness` -- that's "diagnostics", with an "s" at the end. Clang also defines `CodeGenOptions::DiagnosticsWithHotness`. LLVM, on the other hand, defines `LLVMContext::getDiagnosticHotnessRequested` -- that's "diagnostic", not "diagnostics". It's a small difference, but it's confusing, typo-inducing, and frustrating. Add a new method with the spelling "diagnostics", and "deprecate" the old spelling. Reviewers: anemet, davidxl Reviewed By: anemet Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D34864 llvm-svn: 306848
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Add !associated metadata.Evgeniy Stepanov2017-03-171-0/+1
| | | | | | | | | | | | | | | | This is an ELF-specific thing that adds SHF_LINK_ORDER to the global's section pointing to the metadata argument's section. The effect of that is a reverse dependency between sections for the linker GC. !associated does not change the behavior of global-dce. The global may also need to be added to llvm.compiler.used. Since SHF_LINK_ORDER is per-section, !associated effectively enables fdata-sections for the affected globals, the same as comdats do. Differential Revision: https://reviews.llvm.org/D29104 llvm-svn: 298157
* IR, X86: Understand !absolute_symbol metadata on global variables.Peter Collingbourne2016-12-081-0/+1
| | | | | | | | | | | | | | | | | Summary: Attaching !absolute_symbol to a global variable does two things: 1) Marks it as an absolute symbol reference. 2) Specifies the value range of that symbol's address. Teach the X86 backend to allow absolute symbols to appear in place of immediates by extending the relocImm and mov64imm32 matchers. Start using relocImm in more places where it is legal. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html Differential Revision: https://reviews.llvm.org/D25878 llvm-svn: 289087
* IR: Reduce the amount of boilerplate required for a metadata kind. NFCI.Peter Collingbourne2016-12-061-107/+29
| | | | llvm-svn: 288867
* Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC)Mehdi Amini2016-11-191-2/+2
| | | | | | | | | | | | | | Summary: This makes it explicit that ownership is taken. Also replace all `new` with make_unique<> at call sites. Reviewers: anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26884 llvm-svn: 287449
* Use profile info to set function section prefix to group hot/cold functions.Dehao Chen2016-10-181-0/+5
| | | | | | | | | | | | | | | | Summary: The original implementation is in r261607, which was reverted in r269726 to accomendate the ProfileSummaryInfo analysis pass. The new implementation: 1. add a new metadata for function section prefix 2. query against ProfileSummaryInfo in CGP to set the correct section prefix for each function 3. output the section prefix set by CGP Reviewers: davidxl, eraman Subscribers: vsk, llvm-commits Differential Revision: https://reviews.llvm.org/D24989 llvm-svn: 284533
* Output optimization remarks in YAMLAdam Nemet2016-09-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Re-committed after moving the template specialization under the yaml namespace. GCC was complaining about this.) This allows various presentation of this data using an external tool. This was first recommended here[1]. As an example, consider this module: 1 int foo(); 2 int bar(); 3 4 int baz() { 5 return foo() + bar(); 6 } The inliner generates these missed-optimization remarks today (the hotness information is pulled from PGO): remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30) remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30) Now with -pass-remarks-output=<yaml-file>, we generate this YAML file: --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 } Function: baz Hotness: 30 Args: - Callee: foo - String: will not be inlined into - Caller: baz ... --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 } Function: baz Hotness: 30 Args: - Callee: bar - String: will not be inlined into - Caller: baz ... This is a summary of the high-level decisions: * There is a new streaming interface to emit optimization remarks. E.g. for the inliner remark above: ORE.emit(DiagnosticInfoOptimizationRemarkMissed( DEBUG_TYPE, "NotInlined", &I) << NV("Callee", Callee) << " will not be inlined into " << NV("Caller", CS.getCaller()) << setIsVerbose()); NV stands for named value and allows the YAML client to process a remark using its name (NotInlined) and the named arguments (Callee and Caller) without parsing the text of the message. Subsequent patches will update ORE users to use the new streaming API. * I am using YAML I/O for writing the YAML file. YAML I/O requires you to specify reading and writing at once but reading is highly non-trivial for some of the more complex LLVM types. Since it's not clear that we (ever) want to use LLVM to parse this YAML file, the code supports and asserts that we're writing only. On the other hand, I did experiment that the class hierarchy starting at DiagnosticInfoOptimizationBase can be mapped back from YAML generated here (see D24479). * The YAML stream is stored in the LLVM context. * In the example, we can probably further specify the IR value used, i.e. print "Function" rather than "Value". * As before hotness is computed in the analysis pass instead of DiganosticInfo. This avoids the layering problem since BFI is in Analysis while DiagnosticInfo is in IR. [1] https://reviews.llvm.org/D19678#419445 Differential Revision: https://reviews.llvm.org/D24587 llvm-svn: 282539
* Revert "Output optimization remarks in YAML"Adam Nemet2016-09-271-8/+0
| | | | | | | | This reverts commit r282499. The GCC bots are failing llvm-svn: 282503
* Output optimization remarks in YAMLAdam Nemet2016-09-271-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows various presentation of this data using an external tool. This was first recommended here[1]. As an example, consider this module: 1 int foo(); 2 int bar(); 3 4 int baz() { 5 return foo() + bar(); 6 } The inliner generates these missed-optimization remarks today (the hotness information is pulled from PGO): remark: /tmp/s.c:5:10: foo will not be inlined into baz (hotness: 30) remark: /tmp/s.c:5:18: bar will not be inlined into baz (hotness: 30) Now with -pass-remarks-output=<yaml-file>, we generate this YAML file: --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 10 } Function: baz Hotness: 30 Args: - Callee: foo - String: will not be inlined into - Caller: baz ... --- !Missed Pass: inline Name: NotInlined DebugLoc: { File: /tmp/s.c, Line: 5, Column: 18 } Function: baz Hotness: 30 Args: - Callee: bar - String: will not be inlined into - Caller: baz ... This is a summary of the high-level decisions: * There is a new streaming interface to emit optimization remarks. E.g. for the inliner remark above: ORE.emit(DiagnosticInfoOptimizationRemarkMissed( DEBUG_TYPE, "NotInlined", &I) << NV("Callee", Callee) << " will not be inlined into " << NV("Caller", CS.getCaller()) << setIsVerbose()); NV stands for named value and allows the YAML client to process a remark using its name (NotInlined) and the named arguments (Callee and Caller) without parsing the text of the message. Subsequent patches will update ORE users to use the new streaming API. * I am using YAML I/O for writing the YAML file. YAML I/O requires you to specify reading and writing at once but reading is highly non-trivial for some of the more complex LLVM types. Since it's not clear that we (ever) want to use LLVM to parse this YAML file, the code supports and asserts that we're writing only. On the other hand, I did experiment that the class hierarchy starting at DiagnosticInfoOptimizationBase can be mapped back from YAML generated here (see D24479). * The YAML stream is stored in the LLVM context. * In the example, we can probably further specify the IR value used, i.e. print "Function" rather than "Value". * As before hotness is computed in the analysis pass instead of DiganosticInfo. This avoids the layering problem since BFI is in Analysis while DiagnosticInfo is in IR. [1] https://reviews.llvm.org/D19678#419445 Differential Revision: https://reviews.llvm.org/D24587 llvm-svn: 282499
* [OptRemark,LDist] RFC: Add hotness attributeAdam Nemet2016-07-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first set of changes implementing the RFC from http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334 This is a cross-sectional patch; rather than implementing the hotness attribute for all optimization remarks and all passes in a patch set, it implements it for the 'missed-optimization' remark for Loop Distribution. My goal is to shake out the design issues before scaling it up to other types and passes. Hotness is computed as an integer as the multiplication of the block frequency with the function entry count. It's only printed in opt currently since clang prints the diagnostic fields directly. E.g.: remark: /tmp/t.c:3:3: loop not distributed: use -Rpass-analysis=loop-distribute for more info (hotness: 300) A new API added is similar to emitOptimizationRemarkMissed. The difference is that it additionally takes a code region that the diagnostic corresponds to. From this, hotness is computed using BFI. The new API is exposed via an analysis pass so that it can be made dependent on LazyBFI. (Thanks to Hal for the analysis pass idea.) This feature can all be enabled by setDiagnosticHotnessRequested in the LLVM context. If this is off, LazyBFI is not calculated (D22141) so there should be no overhead. A new command-line option is added to turn this on in opt. My plan is to switch all user of emitOptimizationRemark* to use this module instead. Reviewers: hfinkel Subscribers: rcox2, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D21771 llvm-svn: 275583
* IR: New representation for CFI and virtual call optimization pass metadata.Peter Collingbourne2016-06-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call optimization. 2. It is represented using a global named metadata node, rather than being directly associated with a global. This makes it harder to manipulate the metadata when rebuilding global variables, summarise it as part of ThinLTO and drop unused metadata when associated globals are dropped. For this reason, CFI does not currently work correctly when both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable globals, and fails to associate metadata with the rebuilt globals. As I understand it, the same problem could also affect ASan, which rebuilds globals with a red zone. This patch solves both of those problems in the following way: 1. Rename the metadata to "type metadata". This new name reflects how the metadata is currently being used (i.e. to represent type information for CFI and vtable opt). The new name is reflected in the name for the associated intrinsic (llvm.type.test) and pass (LowerTypeTests). 2. Attach metadata directly to the globals that it pertains to, rather than using the "llvm.bitsets" global metadata node as we are doing now. This is done using the newly introduced capability to attach metadata to global variables (r271348 and r271358). See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html Differential Revision: http://reviews.llvm.org/D21053 llvm-svn: 273729
* [llc] New diagnostic handlerRenato Golin2016-05-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | Without a diagnostic handler installed, llc's behaviour is to exit on the first error that it encounters. This is very different from the behaviour of clang and other front ends, which try to gather as many errors as possible before exiting. This commit adds a diagnostic handler to llc, allowing it to find and report more than one error. The old behaviour is preserved under a flag (-exit-on-error). Some of the tests fail with the new diagnostic handler, so they have to use the new flag in order to run under the previous behaviour. Some of these are known bugs, others need further investigation. Ideally, we should fix the tests and remove the flag at some point in the future. Reapplied after fixing the LLDB build that was broken due to the new DiagnosticSeverity in LLVMContext.h, and fixed an UB in the new change. Patch by Diana Picus. llvm-svn: 269655
* Revert "[llc] New diagnostic handler"Renato Golin2016-05-141-2/+1
| | | | | | | | | | | | This reverts commit r269563. Even though now it passes all LLDB bots after a local fix, there's a new buildbot it fails with tests that we hadn't seen locally: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/15647 Adding those tests to the list to investigate. llvm-svn: 269568
* [llc] New diagnostic handlerRenato Golin2016-05-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | Without a diagnostic handler installed, llc's behaviour is to exit on the first error that it encounters. This is very different from the behaviour of clang and other front ends, which try to gather as many errors as possible before exiting. This commit adds a diagnostic handler to llc, allowing it to find and report more than one error. The old behaviour is preserved under a flag (-exit-on-error). Some of the tests fail with the new diagnostic handler, so they have to use the new flag in order to run under the previous behaviour. Some of these are known bugs, others need further investigation. Ideally, we should fix the tests and remove the flag at some point in the future. Reapplied after fixing the LLDB build that was broken due to the new DiagnosticSeverity in LLVMContext.h. Patch by Diana Picus. llvm-svn: 269563
* Revert "[llc] New diagnostic handler"Renato Golin2016-05-131-2/+1
| | | | | | | | This reverts commit r269428, as it breaks the LLDB build. We need to understand how to change LLDB in the same way as LLC before landing this again. llvm-svn: 269432
* [llc] New diagnostic handlerRenato Golin2016-05-131-1/+2
| | | | | | | | | | | | | | | | | | | Without a diagnostic handler installed, llc's behaviour is to exit on the first error that it encounters. This is very different from the behaviour of clang and other front ends, which try to gather as many errors as possible before exiting. This commit adds a diagnostic handler to llc, allowing it to find and report more than one error. The old behaviour is preserved under a flag (-exit-on-error). Some of the tests fail with the new diagnostic handler, so they have to use the new flag in order to run under the previous behaviour. Some of these are known bugs, others need further investigation. Ideally, we should fix the tests and remove the flag at some point in the future. Patch by Diana Picus. llvm-svn: 269428
* Fix some Clang-tidy modernize and Include What You Use warnings.Eugene Zelenko2016-04-281-6/+16
| | | | | | Differential revision: http://reviews.llvm.org/D19673 llvm-svn: 267910
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-0/+4
| | | | | | | | | | support. The original commit was reverted because of a buildbot problem with LazyCallGraph::SCC handling (not related to the OptBisect handling). Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267231
* Revert "Initial implementation of optimization bisect support."Vedant Kumar2016-04-221-4/+0
| | | | | | | | This reverts commit r267022, due to an ASan failure: http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1549 llvm-svn: 267115
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-0/+4
| | | | | | | | | | | | This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations. The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used. The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way. Differential Revision: http://reviews.llvm.org/D19172 llvm-svn: 267022
* IR: Use Optional instead of unique_ptr for debug info ODR type map, NFCDuncan P. N. Exon Smith2016-04-191-2/+1
| | | | | | Save a level of malloc indirection. llvm-svn: 266749
* IR: getOrInsertODRUniquedType => DICompositeType::getODRType, NFCDuncan P. N. Exon Smith2016-04-191-6/+0
| | | | | | | | | | | | | | Lift the API for debug info ODR type uniquing up a layer. Instead of clients managing the map directly on the LLVMContext, add a static method to DICompositeType called getODRType and handle the map in the background. Also adds DICompositeType::getODRTypeIfExists, so far just for convenience in the unit tests. This simplifies the logic in LLParser and BitcodeReader. Because of argument spam there are actually a few more lines of code now; I'll see if I come up with a reasonable way to clean that up. llvm-svn: 266742
* IR: Require DICompositeType for ODR uniquing type mapDuncan P. N. Exon Smith2016-04-191-2/+3
| | | | | | | | Tighten up the API for debug info ODR type uniquing in LLVMContext. The only reason to allow other DIType subclasses is to make the unit tests prettier :/. llvm-svn: 266737
* IR: Rename API for enabling ODR uniquing of DITypes, NFCDuncan P. N. Exon Smith2016-04-191-5/+5
| | | | | | | | | | | As per David's review, rename everything in the new API for ODR type uniquing of debug info. ensureDITypeMap => enableDebugTypeODRUniquing destroyDITypeMap => disableDebugTypeODRUniquing hasDITypeMap => isODRUniquingDebugTypes llvm-svn: 266713
* IR: Use an explicit map for debug info type uniquingDuncan P. N. Exon Smith2016-04-171-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than relying on the structural equivalence of DICompositeType to merge type definitions, use an explicit map on the LLVMContext that LLParser and BitcodeReader consult when constructing new nodes. Each non-forward-declaration DICompositeType with a non-empty 'identifier:' field is stored/loaded from the type map, and the first definiton will "win". This map is opt-in: clients that expect ODR types from different modules to be merged must call LLVMContext::ensureDITypeMap. - Clients that just happen to load more than one Module in the same LLVMContext won't magically merge types. - Clients (like LTO) that want to continue to merge types based on ODR identifiers should opt-in immediately. I have updated LTOCodeGenerator.cpp, the two "linking" spots in gold-plugin.cpp, and llvm-link (unless -disable-debug-info-type-map) to set this. With this in place, it will be straightforward to remove the DITypeRef concept (i.e., referencing types by their 'identifier:' string rather than pointing at them directly). llvm-svn: 266549
* Nuke getGlobalContext() from LLVM (but the C API)Mehdi Amini2016-04-141-6/+0
| | | | | | | | | | The only use for getGlobalContext() is in the C API. Let's just move the static global here and nuke the C++ API. Differential Revision: http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266380
* 80 lines column after renaming "shouldDiscardValueNames" (NFC)Mehdi Amini2016-04-021-1/+3
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265212
* Rename Context::discardValueNames() to shouldDiscardValueNames() (NFC)Mehdi Amini2016-04-021-1/+1
| | | | | | | Suggested by Sean Silva. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265211
* [LoopVectorize] Don't unconditionally print vectorization diagnosticsAkira Hatanaka2016-04-011-21/+3
| | | | | | | | | | | | | | | | | when compiling with LTO. r244523 a new class DiagnosticInfoOptimizationRemarkAnalysisAliasing for optimization analysis remarks related to pointer aliasing without guarding it in isDiagnosticEnabled in LLVMContext.cpp. This caused the diagnostic message to be printed unconditionally when compiling with LTO. This commit cleans up isDiagnosticEnabled and makes sure all the vectorization optimization remarks are guarded. rdar://problem/25382153 llvm-svn: 265084
* IR: Constify LLVMContext::discardValueNames, NFCDuncan P. N. Exon Smith2016-03-301-1/+1
| | | | llvm-svn: 264823
* IR: Reserve an MDKind for !llvm.loop; NFCDuncan P. N. Exon Smith2016-03-251-0/+5
| | | | | | | | | | This reserves an MDKind for !llvm.loop, which allows callers to avoid a string-based lookup. I'm not sure why it was missing. There should be no functionality change here, just a small compile-time speedup. llvm-svn: 264371
* Add a flag to the LLVMContext to disable name for Value other than GlobalValueMehdi Amini2016-03-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is intended to be a performance flag, on the same level as clang cc1 option "--disable-free". LLVM will never initialize it by default, it will be up to the client creating the LLVMContext to request this behavior. Clang will do it by default in Release build (just like --disable-free). "opt" and "llc" can opt-in using -disable-named-value command line option. When performing LTO on llvm-tblgen, the initial merging of IR peaks at 92MB without this patch, and 86MB after this patch,setNameImpl() drops from 6.5MB to 0.5MB. The total link time goes from ~29.5s to ~27.8s. Compared to a compile-time flag (like the IRBuilder one), it performs very close. I profiled on SROA and obtain these results: 420ms with IRBuilder that preserve name 372ms with IRBuilder that strip name 375ms with IRBuilder that preserve name, and a runtime flag to strip Reviewers: chandlerc, dexonsmith, bogner Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263086
* Add a "gc-transition" operand bundleSanjoy Das2016-01-201-0/+5
| | | | | | | | | | | | | | | | | | | Summary: This adds a new kind of operand bundle to LLVM denoted by the `"gc-transition"` tag. Inputs to `"gc-transition"` operand bundle are lowered into the "transition args" section of `gc.statepoint` by `RewriteStatepointsForGC`. This removes the last bit of functionality that was unsupported in the deopt bundle based code path in `RewriteStatepointsForGC`. Reviewers: pgavlin, JosephTremoulet, reames Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D16342 llvm-svn: 258338
* Remove static global GCNames from Function.cpp and move it to the ContextMehdi Amini2016-01-081-0/+16
| | | | | | | | | This remove the need for locking when deleting a function. Differential Revision: http://reviews.llvm.org/D15988 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 257139
* [WinEH] Use operand bundles to describe call sitesDavid Majnemer2015-12-151-0/+5
| | | | | | | | | | | | | | | | | SimplifyCFG allows tail merging with code which terminates in unreachable which, in turn, makes it possible for an invoke to end up in a funclet which it was not originally part of. Using operand bundles on invokes allows us to determine whether or not an invoke was part of a funclet in the source program. Furthermore, it allows us to unambiguously answer questions about the legality of inlining into call sites which the personality may have trouble with. Differential Revision: http://reviews.llvm.org/D15517 llvm-svn: 255674
* Introduce deoptimization operand bundlesSanjoy Das2015-11-111-0/+5
| | | | | | | | | | | | | | | | | | | | | Summary: This change introduces the notion of "deoptimization" operand bundles. LLVM can recognize and optimize these in more precise ways than it can a generic "unknown" operand bundles. The current form of this special recognition / optimization is an enum entry in LLVMContext, a LangRef blurb and a verifier rule. Over time we will teach LLVM to do more aggressive optimization around deoptimization operand bundles, exploiting known facts about kinds of state deoptimization operand bundles are allowed to track. Reviewers: reames, majnemer, chandlerc, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14551 llvm-svn: 252806
OpenPOWER on IntegriCloud