summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/IPO/GlobalOpt.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Use unique_ptr to handle GlobalOpt's Evaluator membersDavid Blaikie2014-04-211-17/+10
| | | | llvm-svn: 206790
* Simplify expression that was explicitly naming an operator overload in a call.David Blaikie2014-04-211-1/+1
| | | | llvm-svn: 206788
* Revert r204076 for now - it caused significant regressions in a number ofLang Hames2014-03-231-47/+78
| | | | | | | | benchmarks. <rdar://problem/16368461> llvm-svn: 204558
* Use range metadata instead of introducing selects.Dan Gohman2014-03-171-78/+47
| | | | | | | | | | | | | | | | When GlobalOpt has determined that a GlobalVariable only ever has two values, it would convert the GlobalVariable to a boolean, and introduce SelectInsts at every load, to choose between the two possible values. These SelectInsts introduce overhead and other unpleasantness. This patch makes GlobalOpt just add range metadata to loads from such GlobalVariables instead. This enables the same main optimization (as seen in test/Transforms/GlobalOpt/integer-bool.ll), without introducing selects. The main downside is that it doesn't get the memory savings of shrinking such GlobalVariables, but this is expected to be negligible. llvm-svn: 204076
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-67/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [C++11] Revert uses of lambdas with array_pod_sort.Benjamin Kramer2014-03-071-4/+5
| | | | | | Looks like GCC implements the lambda->function pointer conversion differently. llvm-svn: 203294
* [C++11] Convert sort predicates into lambdas.Benjamin Kramer2014-03-071-5/+4
| | | | | | No functionality change. llvm-svn: 203288
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-051-2/+2
| | | | | | class. llvm-svn: 202953
OpenPOWER on IntegriCloud