llvm/test/Transforms/Reassociate, branch release_33http://llvm.orghttps://git.amat.us/llvm/atom/test/Transforms/Reassociate?h=release_332013-04-30T17:52:57ZTBAA: remove !tbaa from testing cases if not used.2013-04-30T17:52:57ZManman Renmren@apple.com2013-04-30T17:52:57Zurn:sha1:2dc50d306752c8672d1543feb88517705cdb25e7
This will make it easier to turn on struct-path aware TBAA since the metadata
format will change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180796 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a XOR reassociation bug. 2013-04-27T18:02:12ZShuxin Yangshuxin.llvm@gmail.com2013-04-27T18:02:12Zurn:sha1:4d4c54d29ff911f59fe2be1a31331dbcbb741f5f
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
Correct assertion condition2013-04-01T18:13:05ZShuxin Yangshuxin.llvm@gmail.com2013-04-01T18:13:05Zurn:sha1:ad26993e1a9b147c3ca4b170ab2eba260f89a1ac
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:2013-03-30T02:15:01ZShuxin Yangshuxin.llvm@gmail.com2013-03-30T02:15:01Zurn:sha1:2d1001064989b7fa79507816fc17d467fc00a2f2
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
Tests: rewrite 'opt ... %s' to 'opt ... < %s' so that opt does not emit a ModuleID2012-12-30T02:33:22ZDmitri Gribenkogribozavr@gmail.com2012-12-30T02:33:22Zurn:sha1:a6542923b8ad94d791a12d3d5ae3e62a611f0383
This is done to avoid odd test failures, like the one fixed in r171243.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171250 91177308-0d34-0410-b5e6-96231b3b80d8
Fix PR14060, an infinite loop in reassociate. The problem was that one of the2012-11-18T19:27:01ZDuncan Sandsbaldrick@free.fr2012-11-18T19:27:01Zurn:sha1:b8e1111fbf71766903d2fc7b158dc612df097ea3
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,2012-11-15T09:58:38ZDuncan Sandsbaldrick@free.fr2012-11-15T09:58:38Zurn:sha1:7ecfcc163956a9e27845ac217f6c650658631030
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 r1677402012-11-13T00:08:49ZShuxin Yangshuxin.llvm@gmail.com2012-11-13T00:08:49Zurn:sha1:4df2826166f1339eb7ddf5c5c84565fccb794de8
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 Reassociate pass.2012-11-12T19:34:11ZShuxin Yangshuxin.llvm@gmail.com2012-11-12T19:34:11Zurn:sha1:0a46bf13a3b6c412749b874b52c8234b027b7134
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. This2012-07-26T09:26:40ZDuncan Sandsbaldrick@free.fr2012-07-26T09:26:40Zurn:sha1:20b2d21509b3d5a10ec5d7be6dea8afa9e92fdee
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