summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO/GlobalOpt.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [GlobalOpt] Demote globals to locals more aggressivelyJames Molloy2015-11-151-7/+76
| | | | | | | | | | | | | | | | Global to local demotion can speed up programs that use globals a lot. It is particularly useful with LTO, when the entire call graph is known and most functions have been internalized. For a global to be demoted, it must only be accessed by one function and that function: 1. Must never recurse directly or indirectly, else the GV would be clobbered. 2. Must never rely on the value in GV at the start of the function (apart from the initializer). GlobalOpt can already do this, but it is hamstrung and only ever tries to demote globals inside "main", because C++ gives extra guarantees about how main is called - once and only once. In LTO mode, we can often prove the first property (if the function is internal by this point, we know enough about the callgraph to determine if it could possibly recurse). FunctionAttrs now infers the "norecurse" attribute for this reason. The second property can be proven for a subset of functions by proving that all loads from GV are dominated by a store to GV. This is conservative in the name of compile time - this only requires a DominatorTree which is fairly cheap in the grand scheme of things. We could do more fancy stuff with MemoryDependenceAnalysis too to catch more cases but this appears to catch most of the useful ones in my testing. llvm-svn: 253168
* [GlobalOpt] Make sure all debug lines end with '\n'James Molloy2015-11-131-2/+2
| | | | | | GlobalVariable::print() used to emit a newline. It hasn't for a while now, but these debug lines weren't updated. llvm-svn: 253030
* [GlobalOpt] Coding style - remove function names from doxygen commentsJames Molloy2015-11-131-126/+115
| | | | | | Suggested by Mehdi in the review of D14148. llvm-svn: 253029
* GlobalOpt should maintain externally_initialized when splitting aggregatesOliver Stannard2015-11-091-0/+2
| | | | | | | | | | | | | When GlobalOpt splits an internal, global variable with an aggregate type, it should propagate the externally_initialized flag to the newly created globals. This makes the pass safe for our downstream use of this flag, while still allowing some useful optimisations (such as removing dead parts of the split aggregate) to be performed. Differential Revision: http://reviews.llvm.org/D13382 llvm-svn: 252490
* [GlobalOpt] Add newlines to DEBUG messagesJames Molloy2015-10-281-4/+4
| | | | | | | | I think these were affected by a change way back when to stop printing newlines in Value::dump() by default. This change simply allows the debug output to be readable. NFC. llvm-svn: 251517
* IPO: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-131-18/+21
| | | | llvm-svn: 250187
* GlobalOpt does not treat externally_initialized globals correctlyOliver Stannard2015-10-121-1/+1
| | | | | | | | GlobalOpt currently merges stores into the initialisers of internal, externally_initialized globals, but should not do so as the value of the global may change between the initialiser and any code in the module being run. llvm-svn: 250035
* [GlobalOpt] Sort members of llvm.used deterministicallySean Silva2015-09-281-1/+2
| | | | | | | | | | | | | | | | | Patch by Jake VanAdrighem! Summary: Fix the way we sort the llvm.used and llvm.compiler.used members. This bug seems to have been introduced in rL183756 through a set of improper casts to GlobalValue*. In subsequent patches this problem was missed and transformed into a getName call on a ConstantExpr. Reviewers: silvas Subscribers: silvas, llvm-commits Differential Revision: http://reviews.llvm.org/D12851 llvm-svn: 248728
* Assume intrinsic handling in global optPiotr Padlewski2015-08-251-0/+4
| | | | | | | | | | | | | | It doesn't solve the problem, when for example we load something, and then assume that it is the same as some constant value, because globalopt will fail on unknown load instruction. The proposed solution would be to skip some instructions that we can't evaluate and they are safe to skip (f.e. load, assume and many others) and see if they are required to perform optimization (f.e. we don't care about ephemeral instructions that may appear using @llvm.assume()) http://reviews.llvm.org/D12266 llvm-svn: 245919
* Revert "Improve merging of stores from static constructors in GlobalOpt"Anthony Pesch2015-07-221-249/+77
| | | | | | This reverts commit 0a9dee959a30b81b9e7df64c9a58ff9898c24024. llvm-svn: 242954
* Revert "IPO: Avoid brace initialization of a map, some versions of libc++ ↵Anthony Pesch2015-07-221-4/+1
| | | | | | | | don't like it" This reverts commit fc2dad0c68f8d32273d3c2d790ed496961f829af. llvm-svn: 242953
* IPO: Avoid brace initialization of a map, some versions of libc++ don't like itJustin Bogner2015-07-221-1/+4
| | | | | | | | | Should fix the build failure on these darwin bots: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/12427/ http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/10389/ llvm-svn: 242945
* Improve merging of stores from static constructors in GlobalOptAnthony Pesch2015-07-221-77/+249
| | | | | | | | | | | | | | | | | | | Summary: While working on a project I wound up generating a fairly large lookup table (10k entries) of callbacks inside of a static constructor. Clang was taking upwards of ~10 minutes to compile the lookup table. I generated a smaller test case (http://www.inolen.com/static_initializer_test.ll) that, after running with -ftime-report, pointed fingers at GlobalOpt and MemCpyOptimizer. Running globalopt took around ~9 minutes. The slowdown came from how GlobalOpt merged stores from static constructors individually into the global initializer in EvaluateStaticConstructor. For each store it discovered and wanted to commit, it would copy the existing global initializer and then merge in the individual store. I changed this so that stores are now grouped by global, and sorted from most significant to least significant by their GEP indexes (e.g. a store to GEP 0, 0 comes before GEP 0, 0, 1). With this representation, the existing initializer can be copied and all new stores merged into it in a single pass. With this patch and http://reviews.llvm.org/D11198, the lookup table that was taking ~10 minutes to compile now compiles in around 5 seconds. I've ran 'make check' and the test-suite, which all passed. I'm not really sure who to tag as a reviewer, Lang mentioned that Chandler may be appropriate. Reviewers: chandlerc, nlewycky Subscribers: nlewycky, llvm-commits Differential Revision: http://reviews.llvm.org/D11200 llvm-svn: 242935
* Test commit, added blank lineAnthony Pesch2015-07-221-0/+1
| | | | llvm-svn: 242923
* Use foreach loop over constant operands. NFC.Pete Cooper2015-06-251-4/+2
| | | | | | | A number of places had explicit loops over Constant::operands(). Just use foreach loops where possible. llvm-svn: 240694
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-2/+2
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-2/+2
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* Recommit r236670: [opaque pointer type] Pass explicit pointer type through ↵David Blaikie2015-05-071-4/+2
| | | | | | | | | | GEP constant folding"" Clang regressions were caused by more stringent assertion checking introduced by this change. Small fix needed to clang has been committed in r236751. llvm-svn: 236752
* Revert "[opaque pointer type] Pass explicit pointer type through GEP ↵David Blaikie2015-05-061-2/+4
| | | | | | | | | | constant folding" Causes regressions in Clang. Reverting while I investigate. This reverts commit r236670. llvm-svn: 236678
* [opaque pointer type] Pass explicit pointer type through GEP constant foldingDavid Blaikie2015-05-061-4/+2
| | | | llvm-svn: 236670
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-6/+9
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.Benjamin Kramer2015-03-231-1/+1
| | | | llvm-svn: 232998
* [opaque pointer type] more gep API migrationsDavid Blaikie2015-03-141-1/+1
| | | | | | | | | | Adding nullptr to all the IRBuilder stuff because it's the first thing that fails to build when testing without the back-compat functions, so I'll keep having to re-add these locally for each chunk of migration I do. Might as well check them in to save me the churn. Eventually I'll have to migrate these too, but I'm going breadth-first. llvm-svn: 232270
* [opaque pointer type] Start migrating GEP creation to explicitly specify the ↵David Blaikie2015-03-141-5/+5
| | | | | | | | | | | | | | | pointee type I'm just going to migrate these in a pretty ad-hoc & incremental way - providing the backwards compatible API for now, then locally removing it, fixing a few callers, adding it back in and commiting those callers. Rinse, repeat. The assertions should ensure that if I get this wrong we'll find out about it and not just have one giant patch to revert, recommit, revert, recommit, etc. llvm-svn: 232240
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-58/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* [PM] Separate the TargetLibraryInfo object from the immutable pass.Chandler Carruth2015-01-151-3/+3
| | | | | | | | | | | | | | The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. llvm-svn: 226157
* [PM] Move TargetLibraryInfo into the Analysis library.Chandler Carruth2015-01-151-1/+1
| | | | | | | | | | | | | | | | While the term "Target" is in the name, it doesn't really have to do with the LLVM Target library -- this isn't an abstraction which LLVM targets generally need to implement or extend. It has much more to do with modeling the various runtime libraries on different OSes and with different runtime environments. The "target" in this sense is the more general sense of a target of cross compilation. This is in preparation for porting this analysis to the new pass manager. No functionality changed, and updates inbound for Clang and Polly. llvm-svn: 226078
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-9/+12
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* GlobalOpt: Don't drop unused memberes of a ComdatDavid Majnemer2014-10-081-8/+20
| | | | | | | | | A linkonce_odr member of a COMDAT shouldn't be dropped if we need to keep the entire COMDAT group. This fixes PR21191. llvm-svn: 219283
* Use range based for loops to avoid needing to re-mention SmallPtrSet size.Craig Topper2014-08-241-9/+12
| | | | llvm-svn: 216351
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-15/+13
| | | | | | needing to mention the size. llvm-svn: 216158
* Const-correct and prevent a copy of a SmallPtrSet.Craig Topper2014-08-191-2/+2
| | | | llvm-svn: 215973
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-9/+9
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-9/+9
| | | | | | needing to mention the size. llvm-svn: 215868
* GlobalOpt: Optimize in the face of insertvalue/extractvalueDavid Majnemer2014-08-081-0/+11
| | | | | | | | | | GlobalOpt didn't know how to simulate InsertValueInst or ExtractValueInst. Optimizing these is pretty straightforward. N.B. This came up when looking at clang's IRGen for MS ABI member pointers; they are represented as aggregates. llvm-svn: 215184
* GlobalOpt: Don't swap private for internal linkageDavid Majnemer2014-07-011-3/+3
| | | | | | | | | There were transforms whose *intent* was to downgrade the linkage of external objects to have internal linkage. However, it fired on things with private linkage as well. llvm-svn: 212104
* GlobalOpt: Handle non-zero offsets for aliasesDavid Majnemer2014-07-011-1/+6
| | | | | | | An alias with an aliasee of a non-zero GEP is not trivially replacable with it's aliasee. llvm-svn: 212079
* IR: Add COMDATs to the IRDavid Majnemer2014-06-271-4/+14
| | | | | | | | | | | | | | | | This new IR facility allows us to represent the object-file semantic of a COMDAT group. COMDATs allow us to tie together sections and make the inclusion of one dependent on another. This is required to implement features like MS ABI VFTables and optimizing away certain kinds of initialization in C++. This functionality is only representable in COFF and ELF, Mach-O has no similar mechanism. Differential Revision: http://reviews.llvm.org/D4178 llvm-svn: 211920
* GlobalOpt: Don't optimize thread_local for initializersDavid Majnemer2014-06-261-2/+3
| | | | | | | | Folding a reference to a thread_local variable into another global variable's initializer is very problematic, there is no relocation that exists to represent such an access. llvm-svn: 211762
* GlobalOpt: Don't optimize dllimport for initializersDavid Majnemer2014-06-241-6/+7
| | | | | | | | | Referencing a dllimport variable requires actually instructions, not just a relocation. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4249 llvm-svn: 211571
* Fix most of PR10367.Rafael Espindola2014-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the design of GlobalAlias so that it doesn't take a ConstantExpr anymore. It now points directly to a GlobalObject, but its type is independent of the aliasee type. To avoid changing all alias related tests in this patches, I kept the common syntax @foo = alias i32* @bar to mean the same as now. The cases that used to use cast now use the more general syntax @foo = alias i16, i32* @bar. Note that GlobalAlias now behaves a bit more like GlobalVariable. We know that its type is always a pointer, so we omit the '*'. For the bitcode, a nice surprise is that we were writing both identical types already, so the format change is minimal. Auto upgrade is handled by looking through the casts and no new fields are needed for now. New bitcode will simply have different types for Alias and Aliasee. One last interesting point in the patch is that replaceAllUsesWith becomes smart enough to avoid putting a ConstantExpr in the aliasee. This seems better than checking and updating every caller. A followup patch will delete getAliasedGlobal now that it is redundant. Another patch will add support for an explicit offset. llvm-svn: 209007
* Re-commit r208025, reverted in r208030, with a fix for a conformance issueRichard Smith2014-05-061-4/+3
| | | | | | which GCC detects and Clang does not! llvm-svn: 208033
* Revert r208025, which made buildbots unhappy for unknown reasons.Richard Smith2014-05-061-3/+4
| | | | llvm-svn: 208030
* Add llvm::function_ref (and a couple of uses of it), representing a ↵Richard Smith2014-05-061-4/+3
| | | | | | type-erased reference to a callable object. llvm-svn: 208025
* SLPVectorizer: Lazily allocate the map for block numbering.Benjamin Kramer2014-05-031-6/+7
| | | | | | | | There is no point in creating it if we're not going to vectorize anything. Creating the map is expensive as it creates large values. No functionality change. llvm-svn: 207916
* Teach GlobalDCE how to remove empty global_ctor entries.Nico Weber2014-05-021-157/+7
| | | | | | | | | | | | | | | | | This moves most of GlobalOpt's constructor optimization code out of GlobalOpt into Transforms/Utils/CDtorUtils.{h,cpp}. The public interface is a single function OptimizeGlobalCtorsList() that takes a predicate returning which constructors to remove. GlobalOpt calls this with a function that statically evaluates all constructors, just like it did before. This part of the change is behavior-preserving. Also add a call to this from GlobalDCE with a filter that removes global constructors that contain a "ret" instruction and nothing else – this fixes PR19590. llvm-svn: 207856
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-35/+36
| | | | llvm-svn: 207196
* Don't use default address space arguments in GlobalOptMatt Arsenault2014-04-231-3/+7
| | | | llvm-svn: 207019
* [Modules] Fix potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | | | | | | definition below all of the header #include lines, lib/Transforms/... edition. This one is tricky for two reasons. We again have a couple of passes that define something else before the includes as well. I've sunk their name macros with the DEBUG_TYPE. Also, InstCombine contains headers that need DEBUG_TYPE, so now those headers #define and #undef DEBUG_TYPE around their code, leaving them well formed modular headers. Fixing these headers was a large motivation for all of these changes, as "leaky" macros of this form are hard on the modules implementation. llvm-svn: 206844
OpenPOWER on IntegriCloud