summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/GVN.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [GVN] When merging blocks update LoopInfo if it's availableAdam Nemet2016-12-011-6/+10
| | | | | | | | | | | | | If LoopInfo is available during GVN, BasicAA will use it. However MergeBlockIntoPredecessor does not update LI as it merges blocks. This didn't use to cause problems because LI was freed before GVN/BasicAA. Now with OptimizationRemarkEmitter, the lifetime of LI is extended so LI needs to be kept up-to-date during GVN. Differential Revision: https://reviews.llvm.org/D27288 llvm-svn: 288307
* Revert "[GVN] Basic optimization remark support"Adam Nemet2016-11-301-20/+3
| | | | | | | | This reverts commit r288210. The failure on the stage2 LTO build is back. llvm-svn: 288226
* [GVN] Basic optimization remark supportAdam Nemet2016-11-291-3/+20
| | | | | | | | | | | | | | | | [recommiting patches one-by-one to see which breaks the stage2 LTO bot] Follow-on patches will add more interesting cases. The goal of this patch-set is to get the GVN messages printed in opt-viewer from Dhrystone as was presented in my Dev Meeting talk. This is the optimization view for the function (the last remark in the function has a bug which is fixed in this series): http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L430 Differential Revision: https://reviews.llvm.org/D26488 llvm-svn: 288210
* Revert "[GVN] Basic optimization remark support"Adam Nemet2016-11-291-20/+3
| | | | | | | | | This reverts commit r288046. Trying to see if the revert fixes a compiler crash during a stage2 LTO build with a GVN backtrace. llvm-svn: 288179
* Revert "[GVN, OptDiag] Include the value that is forwarded in load elimination"Adam Nemet2016-11-291-8/+5
| | | | | | | | | This reverts commit r288047. Trying to see if the revert fixes a compiler crash during a stage2 LTO build with a GVN backtrace. llvm-svn: 288178
* Revert "[GVN, OptDiag] Print the interesting instructions involved in missed ↵Adam Nemet2016-11-291-36/+0
| | | | | | | | | | | load-elimination" This reverts commit r288090. Trying to see if the revert fixes a compiler crash during a stage2 LTO build with a GVN backtrace. llvm-svn: 288177
* [GVN, OptDiag] Print the interesting instructions involved in missed ↵Adam Nemet2016-11-291-0/+36
| | | | | | | | | | | | | | | | | | | load-elimination This includes the intervening store and the load/store that we're trying to forward from in the optimization remark for the missed load elimination. This is hooked up under a new mode in ORE that allows for compile-time budget for a bit more analysis to print more insightful messages. This mode is currently enabled for -fsave-optimization-record (-Rpass is trickier since it is controlled in the front-end). With this we can now print the red remark in http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L446 Differential Revision: https://reviews.llvm.org/D26490 llvm-svn: 288090
* [GVN, OptDiag] Include the value that is forwarded in load eliminationAdam Nemet2016-11-281-5/+8
| | | | | | | | | | | | | | | | | | | | | This requires some changes to the opt-diag API. Hal and I have discussed this at the Dev Meeting and came up with a streaming delimiter (setExtraArgs) to solve this. Arguments after this delimiter are only included in the optimization records and not in the remarks printed in the compiler output. (Note, how in the test the content of the YAML file changes but the remarks on the compiler output don't.) This implements the green GVN message with a bug fix at line http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L446 The fix is that now we properly include the constant value in the message: "load of type i32 eliminated in favor of 7" Differential Revision: https://reviews.llvm.org/D26489 llvm-svn: 288047
* [GVN] Basic optimization remark supportAdam Nemet2016-11-281-3/+20
| | | | | | | | | | | | | | Follow-on patches will add more interesting cases. The goal of this patch-set is to get the GVN messages printed in opt-viewer from Dhrystone as was presented in my Dev Meeting talk. This is the optimization view for the function (the last remark in the function has a bug which is fixed in this series): http://lab.llvm.org:8080/artifacts/opt-view_test-suite/build/SingleSource/Benchmarks/Dhrystone/CMakeFiles/dry.dir/html/_org_test-suite_SingleSource_Benchmarks_Dhrystone_dry.c.html#L430 Differential Revision: https://reviews.llvm.org/D26488 llvm-svn: 288046
* Fixed the lost FastMathFlags in GVN(Global Value Numbering).Vyacheslav Klochkov2016-11-221-1/+6
| | | | | | | Reviewer: Hal Finkel. Differential Revision: https://reviews.llvm.org/D26952 llvm-svn: 287700
* Revert "[GVN/PRE] Hoist global values outside of loops."Davide Italiano2016-10-211-58/+26
| | | | | | | | | There's no agreement about this patch. I personally find the PRE machinery of the current GVN hard enough to reason about that I'm not sure I'll try to land this again, instead of working on the rewrite). llvm-svn: 284796
* [GVN] Use defaulted members. No functional change.Benjamin Kramer2016-10-201-10/+3
| | | | llvm-svn: 284726
* [GVN] Consistently use division instead of shift. NFCI.Davide Italiano2016-10-181-2/+2
| | | | | | | This is in line with other places of GVN (e.g. load coercion logic). llvm-svn: 284535
* [GVN] Remove dead code. NFC.Davide Italiano2016-10-181-20/+1
| | | | llvm-svn: 284534
* [GVN/PRE] Hoist global values outside of loops.Davide Italiano2016-10-151-26/+58
| | | | | | | | | | | In theory this could be generalized to move anything where we prove the operands are available, but that would require rewriting PRE. As NewGVN will hopefully come soon, and we're trying to rewrite PRE in terms of NewGVN+MemorySSA, it's probably not worth spending too much time on it. Fix provided by Daniel Berlin! llvm-svn: 284311
* revert r280427Dehao Chen2016-09-081-2/+2
| | | | | | | Refactor replaceDominatedUsesWith to have a flag to control whether to replace uses in BB itself. Summary: This is in preparation for LoopSink pass which calls replaceDominatedUsesWith to update after sinking. llvm-svn: 280949
* Refactor replaceDominatedUsesWith to have a flag to control whether to ↵Dehao Chen2016-09-011-2/+2
| | | | | | | | | | | | | | replace uses in BB itself. Summary: This is in preparation for LoopSink pass which calls replaceDominatedUsesWith to update after sinking. Reviewers: chandlerc, davidxl, danielcdh Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24170 llvm-svn: 280427
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-1/+1
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* [ConstnatFolding] Teach the folder how to fold ConstantVectorDavid Majnemer2016-07-291-6/+9
| | | | | | | | | | | A ConstantVector can have ConstantExpr operands and vice versa. However, the folder had no ability to fold ConstantVectors which, in some cases, was an optimization barrier. Instead, rephrase the folder in terms of Constants instead of ConstantExprs and teach callers how to deal with failure. llvm-svn: 277099
* [GVN] Fold constant expression in GVN.Ekaterina Romanova2016-07-141-22/+33
| | | | | | | | | | | Fix for PR 28418. opt never finishes compiling a test when -gvn option is passed. The problem is caused by the fact that GVN fails to fold a constant expression. Differential Revision: https://reviews.llvm.org/D22185 llvm-svn: 275483
* Reinstate r273711David Majnemer2016-06-251-6/+15
| | | | | | | | | | r273711 was reverted by r273743. The inliner needs to know about any call sites in the inlined function. These were obscured if we replaced a call to undef with an undef but kept the call around. This fixes PR28298. llvm-svn: 273753
* Revert r273711, it caused PR28298.Nico Weber2016-06-241-15/+6
| | | | llvm-svn: 273743
* SimplifyInstruction does not imply DCEDavid Majnemer2016-06-241-6/+15
| | | | | | | We cannot remove an instruction with no uses just because SimplifyInstruction succeeds. It may have side effects. llvm-svn: 273711
* Apply another batch of fixes from clang-tidy's ↵Benjamin Kramer2016-06-171-1/+1
| | | | | | | | performance-unnecessary-value-param. Contains some manual fixes. No functionality change intended. llvm-svn: 273047
* [PM] Preserve the correct set of analyses for GVN.Davide Italiano2016-06-061-1/+6
| | | | llvm-svn: 271934
* [GVN] Switch dump() definition over to LLVM_DUMP_METHOD.Davide Italiano2016-06-061-2/+1
| | | | llvm-svn: 271932
* [GVN] Preserve !range metadata when PRE'ing loadsSanjoy Das2016-05-271-0/+2
| | | | | | | | | | Reviewers: dberlin, reames, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20743 llvm-svn: 271034
* [GVN] PRE of unordered loadsPhilip Reames2016-05-061-8/+4
| | | | | | Again, fairly simple. Only change is ensuring that we actually copy the property of the load correctly. The aliasing legality constraints were already handled by the FRE patches. There's nothing special about unorder atomics from the perspective of the PRE algorithm itself. llvm-svn: 268804
* [GVN] Handle unordered atomics in cross block FREPhilip Reames2016-05-061-5/+5
| | | | | | You'll note there are essentially no code changes here. Cross block FRE heavily reuses code from the block local FRE. All of the tricky parts were done as part of the previous patch and the refactoring that removed the original code duplication. llvm-svn: 268775
* [GVN] Do local FRE for unordered atomic loadsPhilip Reames2016-05-061-4/+21
| | | | | | | | | | This patch is the first in a small series teaching GVN to optimize unordered loads aggressively. This change just handles block local FRE because that's the simplest thing which lets me test MDA, and the AvailableValue pieces. Somewhat suprisingly, MDA appears fine and only a couple of small changes are needed in GVN. Once this is in, I'll tackle non-local FRE and PRE. The former looks like a natural extension of this, the later will require a couple of minor changes. Differential Revision: http://reviews.llvm.org/D19440 llvm-svn: 268770
* [GVN] Minor code cleanup. NFC.Chad Rosier2016-04-281-65/+60
| | | | | | | Differential Revision: http://reviews.llvm.org/D18828 Patch by Aditya Kumar! llvm-svn: 267898
* Re-commit optimization bisect support (r267022) without new pass manager ↵Andrew Kaylor2016-04-221-1/+1
| | | | | | | | | | 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-5/+1
| | | | | | | | 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
* [GVN] Respect fast-math-flags on fcmpsDavid Majnemer2016-04-221-22/+21
| | | | | | | We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
* Initial implementation of optimization bisect support.Andrew Kaylor2016-04-211-1/+5
| | | | | | | | | | | | 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
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* [GVN] Address review comments for D18662Ulrich Weigand2016-04-071-9/+10
| | | | | | | | | | | As suggested by Chandler in his review comments for D18662, this follow-on patch renames some variables in GetLoadValueForLoad and CoerceAvailableValueToLoadType to hopefully make it more obvious which variables hold value sizes and which hold load/store sizes. No functional change intended. llvm-svn: 265687
* [GVN] Fix handling of sub-byte types in big-endian modeUlrich Weigand2016-04-071-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When GVN wants to re-interpret an already available value in a smaller type, it needs to right-shift the value on big-endian systems to ensure the correct bytes are accessed. The shift value is the difference of the sizes of the two types. This is correct as long as both types occupy multiples of full bytes. However, when one of them is a sub-byte type like i1, this no longer holds true: we still need to shift, but only to access the correct *byte*. Accessing bits within the byte requires no shift in either endianness; e.g. an i1 resides in the least-significant bit of its containing byte on both big- and little-endian systems. Therefore, the appropriate shift value to be used is the difference of the *storage* sizes of the two types. This is already handled correctly in one place where such a shift takes place (GetStoreValueForLoad), but is incorrect in two other places: GetLoadValueForLoad and CoerceAvailableValueToLoadType. This patch changes both places to use the storage size as well. Differential Revision: http://reviews.llvm.org/D18662 llvm-svn: 265684
* [PM] Sink the "Expression" type for GVN into the class as a privateChandler Carruth2016-03-111-11/+11
| | | | | | | | | | | | | | | member type. Because of how this type is used by the ValueTable, it cannot actually have hidden visibility. GCC actually nicely warns about this but Clang just silently ... I don't even know. =/ We should do a better job either way though. This should resolve a bunch of the GCC warnings about visibility that the port of GVN triggered and make the visibility story a bit more correct. llvm-svn: 263250
* [PM] The order of evaluation of these analyses is actually significant,Chandler Carruth2016-03-111-5/+10
| | | | | | | | | | | | | | | | | | | | much to my horror, so use variables to fix it in place. This terrifies me. Both basic-aa and memdep will provide more precise information when the domtree and/or the loop info is available. Because of this, if your pass (like GVN) requires domtree, and then queries memdep or basic-aa, it will get more precise results. If it does this in the other order, it gets less precise results. All of the ideas I have for fixing this are, essentially, terrible. Here I've just caused us to stop having unspecified behavior as different implementations evaluate the order of these arguments differently. I'm actually rather glad that they do, or the fragility of memdep and basic-aa would have gone on unnoticed. I've left comments so we don't immediately break this again. This should fix bots whose host compilers evaluate the order of arguments differently from Clang. llvm-svn: 263231
* [PM] Make the AnalysisManager parameter to run methods a reference.Chandler Carruth2016-03-111-6/+6
| | | | | | | | | | | | This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
* [PM] Port GVN to the new pass manager, wire it up, and teach a couple ofChandler Carruth2016-03-111-349/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | tests to run GVN in both modes. This is mostly the boring refactoring just like SROA and other complex transformation passes. There is some trickiness in that GVN's ValueNumber class requires hand holding to get to compile cleanly. I'm open to suggestions about a better pattern there, but I tried several before settling on this. I was trying to balance my desire to sink as much implementation detail into the source file as possible without introducing overly many layers of abstraction. Much like with SROA, the design of this system is made somewhat more cumbersome by the need to support both pass managers without duplicating the significant state and logic of the pass. The same compromise is struck here. I've also left a FIXME in a doxygen comment as the GVN pass seems to have pretty woeful documentation within it. I'd like to submit this with the FIXME and let those more deeply familiar backfill the information here now that we have a nice place in an interface to put that kind of documentaiton. Differential Revision: http://reviews.llvm.org/D18019 llvm-svn: 263208
* [gvn] Fix more indenting and formatting in regions of code that willChandler Carruth2016-03-101-64/+62
| | | | | | | | | | | need to be changed for porting to the new pass manager. Also sink the comment on the ValueTable class back to that class instead of it dangling on an anonymous namespace. No functionality changed. llvm-svn: 263084
* [gvn] Reformat a chunk of the GVN code that is strangely indented priorChandler Carruth2016-03-101-241/+240
| | | | | | | | to restructuring it for porting to the new pass manager. No functionality changed. llvm-svn: 263083
* [PM] Port memdep to the new pass manager.Chandler Carruth2016-03-101-9/+9
| | | | | | | | | | | | | | | | | | | | | | | This is a fairly straightforward port to the new pass manager with one exception. It removes a very questionable use of releaseMemory() in the old pass to invalidate its caches between runs on a function. I don't think this is really guaranteed to be safe. I've just used the more direct port to the new PM to address this by nuking the results object each time the pass runs. While this could cause some minor malloc traffic increase, I don't expect the compile time performance hit to be noticable, and it makes the correctness and other aspects of the pass much easier to reason about. In some cases, it may make things faster by making the sets and maps smaller with better locality. Indeed, the measurements collected by Bruno (thanks!!!) show mostly compile time improvements. There is sadly very limited testing at this point as there are only two tests of memdep, and both rely on GVN. I'll be porting GVN next and that will exercise this heavily though. Differential Revision: http://reviews.llvm.org/D17962 llvm-svn: 263082
* Remove unused variableDavid Majnemer2016-02-121-1/+0
| | | | llvm-svn: 260722
* [GVN] Common code for local and non-local load availability [NFCI]Philip Reames2016-02-121-248/+148
| | | | | | | | | | | | The attached patch removes all of the block local code for performing X-load forwarding by reusing the code used in the non-local case. The motivation here is to remove duplication and in the process increase our test coverage of some fairly tricky code. I have some upcoming changes I'll be proposing in this area and wanted to have the code cleaned up a bit first. Note: The review for this mostly happened in email which didn't make it to phabricator on the 258882 commit thread. Differential Revision: http://reviews.llvm.org/D16608 llvm-svn: 260711
* [GVN] Add clarifying assert [NFCI]Philip Reames2016-01-291-0/+5
| | | | | | Just adding an assert which makes invariants between AnalyzeLoadsFromClobberingLoads and GetLoadValueForLoad slightly more clear. llvm-svn: 259145
* [GVN] Split AvailableValueInBlock into two parts [NFC]Philip Reames2016-01-261-29/+69
| | | | | | | | AvailableValue is the part that represents the potential rematerialization. AvailableValueInBlock is simply a pair of an AvailableValue and a BB which we might materialize it in. This is motivated by http://reviews.llvm.org/D16608. The intent is that we'll have a single function which handles the local case which both local and non-local will use to identify available values. Once that's done, the local case can rematerialize at the use site and the non-local case can do the SSA construction as it does currently. llvm-svn: 258882
* [GVN] Rearrange code to make local vs non-local cases more obvious [NFCI]Philip Reames2016-01-251-13/+18
| | | | llvm-svn: 258747
OpenPOWER on IntegriCloud