llvm/test/Transforms/Reassociate, branch release_32http://llvm.orghttps://git.amat.us/llvm/atom/test/Transforms/Reassociate?h=release_322012-11-22T06:21:31ZMerging r168291: into the 3.2 release branch.2012-11-22T06:21:31ZPawel Wodnickipawel@32bitmicro.com2012-11-22T06:21:31Zurn:sha1:df46b9004b0ac81d6cd37a644e5c8243af0afc61
Fix PR14060, an infinite loop in reassociate. The problem was that one of the
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/branches/release_32@168489 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r168035: into 3.2 release branch.2012-11-21T18:55:44ZPawel Wodnickipawel@32bitmicro.com2012-11-21T18:55:44Zurn:sha1:b30ce3e484f1e7f37a709e6fa7a91712a3d85e97
Fix a crash observed by Shuxin Yang. The issue here is that LinearizeExprTree,
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/branches/release_32@168446 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
Convert all tests using TCL-style quoting to use shell-style quoting.2012-07-02T12:47:22ZChandler Carruthchandlerc@gmail.com2012-07-02T12:47:22Zurn:sha1:4177e6fff50552908bab510f1e896fa974a6f155
This was done through the aid of a terrible Perl creation. I will not
paste any of the horrors here. Suffice to say, it require multiple
staged rounds of replacements, state carried between, and a few
nested-construct-parsing hacks that I'm not proud of. It happens, by
luck, to be able to deal with all the TCL-quoting patterns in evidence
in the LLVM test suite.
If anyone is maintaining large out-of-tree test trees, feel free to poke
me and I'll send you the steps I used to convert things, as well as
answer any painful questions etc. IRC works best for this type of thing
I find.
Once converted, switch the LLVM lit config to use ShTests the same as
Clang. In addition to being able to delete large amounts of Python code
from 'lit', this will also simplify the entire test suite and some of
lit's architecture.
Finally, the test suite runs 33% faster on Linux now. ;]
For my 16-hardware-thread (2x 4-core xeon e5520): 36s -> 24s
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159525 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a reassociate crash on sozefx when compiling with dragonegg+gcc-4.7 due to2012-06-29T13:25:06ZDuncan Sandsbaldrick@free.fr2012-06-29T13:25:06Zurn:sha1:96d2eff5c6713a2c5fd2cd61545e49637c332975
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
Some reassociate optimizations create new instructions, which they insert just2012-06-27T14:19:00ZDuncan Sandsbaldrick@free.fr2012-06-27T14:19:00Zurn:sha1:2d5f8ca3d180832d168e59e2bf3d85317e86287d
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!2012-06-24T01:44:08ZNick Lewyckynicholas@mxc.ca2012-06-24T01:44:08Zurn:sha1:917f99354fa558e50d17191f593f81155b4ab2c3
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, for2012-06-15T08:37:50ZDuncan Sandsbaldrick@free.fr2012-06-15T08:37:50Zurn:sha1:cd117f736c47947af5c6549734549e135e626c5c
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 to2012-06-13T12:15:56ZDuncan Sandsbaldrick@free.fr2012-06-13T12:15:56Zurn:sha1:d34491f6751ae2f8daf3e857c84bcb5b06fba889
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
Use std::map rather than SmallMap because SmallMap assumes that the value has2012-06-12T20:16:51ZDuncan Sandsbaldrick@free.fr2012-06-12T20:16:51Zurn:sha1:ac071eac30953b0913c91a63c3d3d32c627abf05
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