summaryrefslogtreecommitdiff
path: root/lib/Transforms/Scalar/Reassociate.cpp
Commit message (Collapse)AuthorAge
* Use switch instead of if. No functionality change.Jakub Staszak2013-07-22
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186892 91177308-0d34-0410-b5e6-96231b3b80d8
* Reassociate: Remove unnecessary default operator=.Benjamin Kramer2013-07-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185757 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a XOR reassociation bug. Shuxin Yang2013-04-27
| | | | | | | | | | | When Reassociator optimize "(x | C1)" ^ "(X & C2)", it may swap the two subexpressions, however, it forgot to swap cached constants (of C1 and C2) accordingly. rdar://13739160 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180676 91177308-0d34-0410-b5e6-96231b3b80d8
* Redo the fix Benjamin Kramer committed in r178793 about iterator ↵Shuxin Yang2013-04-08
| | | | | | | | | | | | | | | | | | invalidation in Reassociate. I brazenly think this change is slightly simpler than r178793 because: - no "state" in functor - "OpndPtrs[i]" looks simpler than "&Opnds[OpndIndices[i]]" While I can reproduce the probelm in Valgrind, it is rather difficult to come up a standalone testing case. The reason is that when an iterator is invalidated, the stale invalidated elements are not yet clobbered by nonsense data, so the optimizer can still proceed successfully. Thank Benjamin for fixing this bug and generously providing the test case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179062 91177308-0d34-0410-b5e6-96231b3b80d8
* Reassociate: Avoid iterator invalidation.Benjamin Kramer2013-04-04
| | | | | | | | OpndPtrs stored pointers into the Opnd vector that became invalid when the vector grows. Store indices instead. Sadly I only have a large testcase that only triggers under valgrind, so I didn't include it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178793 91177308-0d34-0410-b5e6-96231b3b80d8
* Correct assertion conditionShuxin Yang2013-04-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178484 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement XOR reassociation. It is based on following rules:Shuxin Yang2013-03-30
| | | | | | | | | | | | | | | | rule 1: (x | c1) ^ c2 => (x & ~c1) ^ (c1^c2), only useful when c1=c2 rule 2: (x & c1) ^ (x & c2) = (x & (c1^c2)) rule 3: (x | c1) ^ (x | c2) = (x & c3) ^ c3 where c3 = c1 ^ c2 rule 4: (x | c1) ^ (x & c2) => (x & c3) ^ c1, where c3 = ~c1 ^ c2 It reduces an application's size (in terms of # of instructions) by 8.9%. Reviwed by Pete Cooper. Thanks a lot! rdar://13212115 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178409 91177308-0d34-0410-b5e6-96231b3b80d8
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-02
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-03
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the last bit of constant folding from LinearizeExprTree (most of it wasDuncan Sands2012-11-18
| | | | | | | removed in commit 168035, but I missed this bit). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168292 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix PR14060, an infinite loop in reassociate. The problem was that one of theDuncan Sands2012-11-18
| | | | | | | | | | | operands of the expression being written was wrongly thought to be reusable as an inner node of the expression resulting in it turning up as both an inner node *and* a leaf, creating a cycle in the def-use graph. This would have caused the verifier to blow up if things had gotten that far, however it managed to provoke an infinite loop first. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168291 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a crash observed by Shuxin Yang. The issue here is that LinearizeExprTree,Duncan Sands2012-11-15
| | | | | | | | | | | | | | | the utility for extracting a chain of operations from the IR, thought that it might as well combine any constants it came across (rather than just returning them along with everything else). On the other hand, the factorization code would like to see the individual constants (this is quite reasonable: it is much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6; you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo multiplications of constants as it may at first appear). This patch therefore makes LinearizeExprTree stupider: it now leaves optimizing to the optimization part of reassociate, and sticks to just analysing the IR. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168035 91177308-0d34-0410-b5e6-96231b3b80d8
* revert r167740Shuxin Yang2012-11-13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167787 91177308-0d34-0410-b5e6-96231b3b80d8
* This change is to fix rdar://12571717 which is about assertion in ↵Shuxin Yang2012-11-12
| | | | | | | | | | | | | | | | | | | Reassociate pass. The assertion is trigged when the Reassociater tries to transform expression ... + 2 * n * 3 + 2 * m + ... into: ... + 2 * (n*3 + m). In the process of the transformation, a helper routine folds the constant 2*3 into 6, confusing optimizer which is trying the to eliminate the common factor 2, and cannot find 2 any more. Review is pending. But I'd like commit first in order to help those who are waiting for this fix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167740 91177308-0d34-0410-b5e6-96231b3b80d8
* Stop reassociate from looking through expressions of arbitrary complexity. ThisDuncan Sands2012-07-26
| | | | | | | is a temporary measure until my fix for PR13021 is ready. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160778 91177308-0d34-0410-b5e6-96231b3b80d8
* Clean whitespaces.Nadav Rotem2012-07-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160668 91177308-0d34-0410-b5e6-96231b3b80d8
* Suppress a warning.Nadav Rotem2012-07-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160629 91177308-0d34-0410-b5e6-96231b3b80d8
* Rework this to clarify where the removal of nodes from the queue isDuncan Sands2012-06-29
| | | | | | | really happening. No intended functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159451 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a reassociate crash on sozefx when compiling with dragonegg+gcc-4.7 due toDuncan Sands2012-06-29
| | | | | | | | the optimizers producing a multiply expression with more multiplications than the original (!). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159426 91177308-0d34-0410-b5e6-96231b3b80d8
* Move llvm/Support/IRBuilder.h -> llvm/IRBuilder.hChandler Carruth2012-06-29
| | | | | | | | | | | | | | | | | This was always part of the VMCore library out of necessity -- it deals entirely in the IR. The .cpp file in fact was already part of the VMCore library. This is just a mechanical move. I've tried to go through and re-apply the coding standard's preferred header sort, but at 40-ish files, I may have gotten some wrong. Please let me know if so. I'll be committing the corresponding updates to Clang and Polly, and Duncan has DragonEgg. Thanks to Bill and Eric for giving the green light for this bit of cleanup. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159421 91177308-0d34-0410-b5e6-96231b3b80d8
* Some reassociate optimizations create new instructions, which they insert justDuncan Sands2012-06-27
| | | | | | | | | | | | before the expression root. Any existing operators that are changed to use one of them needs to be moved between it and the expression root, and recursively for the operators using that one. When I rewrote RewriteExprTree I accidentally inverted the logic, resulting in the compacting going down from operators to operands rather than up from operands to the operators using them, oops. Fix this, resolving PR12963. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159265 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove a dangling reference to a deleted instruction. Fixes PR13185!Nick Lewycky2012-06-24
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159096 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix issues (infinite loop and/or crash) with self-referential instructions, forDuncan Sands2012-06-15
| | | | | | | | example degenerate phi nodes and binops that use themselves in unreachable code. Thanks to Charles Davis for the testcase that uncovered this can of worms. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158508 91177308-0d34-0410-b5e6-96231b3b80d8
* It is possible for several constants which aren't individually absorbing toDuncan Sands2012-06-13
| | | | | | | | combine to the absorbing element. Thanks to nbjoerg on IRC for pointing this out. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158399 91177308-0d34-0410-b5e6-96231b3b80d8
* When linearizing a multiplication, return at once if we see a factor of zero,Duncan Sands2012-06-13
| | | | | | | | | | since then the entire expression must equal zero (similarly for other operations with an absorbing element). With this in place a bunch of reassociate code for handling constants is dead since it is all taken care of when linearizing. No intended functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158398 91177308-0d34-0410-b5e6-96231b3b80d8
* Use DenseMap as SmallMap workaround rather than std::map, at Chandler's request.Duncan Sands2012-06-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158371 91177308-0d34-0410-b5e6-96231b3b80d8
* Use std::map rather than SmallMap because SmallMap assumes that the value hasDuncan Sands2012-06-12
| | | | | | | | POD type, causing memory corruption when mapping to APInts with bitwidth > 64. Merge another crash testcase into crash.ll while there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158369 91177308-0d34-0410-b5e6-96231b3b80d8
* Now that Reassociate's LinearizeExprTree can look through arbitrary expressionDuncan Sands2012-06-12
| | | | | | | | | | | | | | | | | | topologies, it is quite possible for a leaf node to have huge multiplicity, for example: x0 = x*x, x1 = x0*x0, x2 = x1*x1, ... rapidly gives a value which is x raised to a vast power (the multiplicity, or weight, of x). This patch fixes the computation of weights by correctly computing them no matter how big they are, rather than just overflowing and getting a wrong value. It turns out that the weight for a value never needs more bits to represent than the value itself, so it is enough to represent weights as APInts of the same bitwidth and do the right overflow-avoiding dance steps when computing weights. As a side-effect it reduces the number of multiplies needed in some cases of large powers. While there, in view of external uses (eg by the vectorizer) I made LinearizeExprTree static, pushing the rank computation out into users. This is progress towards fixing PR13021. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158358 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply commit 158073 with a fix (the testcase was already committed). TheDuncan Sands2012-06-08
| | | | | | | | | | | | | | | | | | | problem was that by moving instructions around inside the function, the pass could accidentally move the iterator being used to advance over the function too. Fix this by only processing the instruction equal to the iterator, and leaving processing of instructions that might not be equal to the iterator to later (later = after traversing the basic block; it could also wait until after traversing the entire function, but this might make the sets quite big). Original commit message: Grab-bag of reassociate tweaks. Unify handling of dead instructions and instructions to reoptimize. Exploit this to more systematically eliminate dead instructions (this isn't very useful in practice but is convenient for analysing some testcase I am working on). No need for WeakVH any more: use an AssertingVH instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158226 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert commit 158073 while waiting for a fix. The issue is that reassociateDuncan Sands2012-06-08
| | | | | | | | | | | | | | | | | | can move instructions within the instruction list. If the instruction just happens to be the one the basic block iterator is pointing to, and it is moved to a different basic block, then we get into an infinite loop due to the iterator running off the end of the basic block (for some reason this doesn't fire any assertions). Original commit message: Grab-bag of reassociate tweaks. Unify handling of dead instructions and instructions to reoptimize. Exploit this to more systematically eliminate dead instructions (this isn't very useful in practice but is convenient for analysing some testcase I am working on). No need for WeakVH any more: use an AssertingVH instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158199 91177308-0d34-0410-b5e6-96231b3b80d8
* Grab-bag of reassociate tweaks. Unify handling of dead instructions andDuncan Sands2012-06-06
| | | | | | | | | | instructions to reoptimize. Exploit this to more systematically eliminate dead instructions (this isn't very useful in practice but is convenient for analysing some testcase I am working on). No need for WeakVH any more: use an AssertingVH instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158073 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix typos found by http://github.com/lyda/misspell-checkBenjamin Kramer2012-06-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157885 91177308-0d34-0410-b5e6-96231b3b80d8
* Since commit 157467, if reassociate isn't actually going to change an expressionDuncan Sands2012-05-26
| | | | | | | | | | | | then it doesn't alter the instructions composing it, however it would continue to move the instructions to just before the expression root. Ensure it doesn't move them either, so now it really does nothing if there is nothing to do. That commit also ensured that nsw etc flags weren't cleared if the expression was not being changed. Tweak this a bit so that it doesn't clear flags on the initial part of a computation either if that part didn't change but later bits did. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157518 91177308-0d34-0410-b5e6-96231b3b80d8
* Move this debug statement earlier so it is easy to see the order inDuncan Sands2012-05-26
| | | | | | | which operands come flying out of the linearization stage. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157512 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the reassociation pass more powerful so that it can handle expressionsDuncan Sands2012-05-25
| | | | | | | | | | | | | | | | | | with arbitrary topologies (previously it would give up when hitting a diamond in the use graph for example). The testcase from PR12764 is now reduced from a pile of additions to the optimal 1617*%x0+208. In doing this I changed the previous strategy of dropping all uses for expression leaves to one of dropping all but one use. This works out more neatly (but required a bunch of tweaks) and is also safer: some recently fixed bugs during recursive linearization were because the linearization code thinks it completely owns a node if it has no uses outside the expression it is linearizing. But if the node was also in another expression that had been linearized (and thus all uses of the node from that expression dropped) then the conclusion that it is completely owned by the expression currently being linearized is wrong. Keeping one use from within each linearized expression avoids this kind of mistake. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157467 91177308-0d34-0410-b5e6-96231b3b80d8
* Calling ReassociateExpression recursively is extremely dangerous since it willDuncan Sands2012-05-08
| | | | | | | | | | | | | | replace the operands of expressions with only one use with undef and generate a new expression for the original without using RAUW to update the original. Thus any copies of the original expression held in a vector may end up referring to some bogus value - and using a ValueHandle won't help since there is no RAUW. There is already a mechanism for getting the effect of recursion non-recursively: adding the value to be recursed on to RedoInsts. But it wasn't being used systematically. Have various places where recursion had snuck in at some point use the RedoInsts mechanism instead. Fixes PR12169. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156379 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach reassociate to commute FMul's and FAdd's in order to canonicalize the ↵Owen Anderson2012-05-07
| | | | | | order of their operands across instructions. This allows for greater CSE opportunities. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156323 91177308-0d34-0410-b5e6-96231b3b80d8
* Add 'landingpad' instructions to the list of instructions to ignore.Bill Wendling2012-05-04
| | | | | | | Also combine the code in the 'assert' statement. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156155 91177308-0d34-0410-b5e6-96231b3b80d8
* Whitespace cleanup.Bill Wendling2012-05-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156034 91177308-0d34-0410-b5e6-96231b3b80d8
* The value held in the vector may be RAUW'ed by some of the canonicalizationBill Wendling2012-05-02
| | | | | | | | methods. Use a weak value handle to keep up with this. PR12245 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155984 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach the reassociate pass to fold chains of multiplies with repeatedChandler Carruth2012-04-26
| | | | | | | | | | | | | | | | | elements to minimize the number of multiplies required to compute the final result. This uses a heuristic to attempt to form near-optimal binary exponentiation-style multiply chains. While there are some cases it misses, it seems to at least a decent job on a very diverse range of inputs. Initial benchmarks show no interesting regressions, and an 8% improvement on SPASS. Let me know if any other interesting results (in either direction) crop up! Credit to Richard Smith for the core algorithm, and helping code the patch itself. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155616 91177308-0d34-0410-b5e6-96231b3b80d8
* Prune some includes and forward declarations.Craig Topper2012-03-26
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153429 91177308-0d34-0410-b5e6-96231b3b80d8
* Silence a bunch (but not all) "variable written but not read" warningsDuncan Sands2011-08-12
| | | | | | | when building with assertions disabled. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137460 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r136503 and r136480 in an effort to fix non-determinism in the ↵Owen Anderson2011-08-02
| | | | | | llvm-gcc buildbots on i386. Devang is looking into the root cause. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136674 91177308-0d34-0410-b5e6-96231b3b80d8
* Clear DbgValues in the end.Devang Patel2011-07-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136503 91177308-0d34-0410-b5e6-96231b3b80d8
* Clean up debug info after reassociation.Devang Patel2011-07-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136480 91177308-0d34-0410-b5e6-96231b3b80d8
* start using the new helper methods a bit.Chris Lattner2011-07-15
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135251 91177308-0d34-0410-b5e6-96231b3b80d8
* Preserve line number information.Devang Patel2011-04-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130450 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix reassociate to use a worklist instead of recursing when newDan Gohman2011-04-12
| | | | | | | | | | reassociation opportunities are exposed. This fixes a bug where the nested reassociation expects to be the IR to be consistent, but it isn't, because the outer reassociation has disconnected some of the operands. rdar://9167457 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129324 91177308-0d34-0410-b5e6-96231b3b80d8
* RecursivelyDeleteTriviallyDeadInstructions only needs aDan Gohman2011-03-10
| | | | | | | | | Value, not an Instruction, so casting is not necessary. Also, it's theoretically possible that the Value is not an Instruction, since WeakVH follows RAUWs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127427 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 10:46:53 +0000