http://llvm.org https://git.amat.us/llvm/atom/test/Transforms?h=release_32 2012-12-10T14:20:28Z 2012-12-10T14:20:28Z Pawel Wodnicki pawel@32bitmicro.com 2012-12-10T14:20:28Z urn:sha1:3f0b779be8218760033ad0ff698ea88c3c7e73c9 Fix PR14548: SROA was crashing on a mixture of i1 and i8 loads and stores. When SROA was evaluating a mixture of i1 and i8 loads and stores, in just a particular case, it would tickle a latent bug where we compared bits to bytes rather than bits to bits. As a consequence of the latent bug, we would allow integers through which were not byte-size multiples, a situation the later rewriting code was never intended to handle. In release builds this could trigger all manner of oddities, but the reported issue in PR14548 was forming invalid bitcast instructions. The only downside of this fix is that it makes it more clear that SROA in its current form is not capable of handling mixed i1 and i8 loads and stores. Sometimes with the previous code this would work by luck, but usually it would crash, so I'm not terribly worried. I'll watch the LNT numbers just to be sure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@169735 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-04T18:29:45Z Pawel Wodnicki pawel@32bitmicro.com 2012-12-04T18:29:45Z urn:sha1:a9020249400f65612fc9f1c0f5cfebe50a58ff85 SROA: Avoid struct and array types early to avoid creating an overly large integer type. Fixes PR14465. Differential Revision: http://llvm-reviews.chandlerc.com/D148 git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@169290 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-30T03:38:58Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-30T03:38:58Z urn:sha1:24d616e51f503d77fe9dca5904991292831b9132 Follow up to 168711: It's safe to base this analysis on the found compare, just return the value for the right predicate. Thanks to Andy for catching this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168974 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-30T03:35:46Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-30T03:35:46Z urn:sha1:73c484255b149cc5392b6dfcc1ef29ed6547cbe4 SCEV: Even if the latch terminator is foldable we can't deduce the result of an unrelated condition with it. Fixes PR14432. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168973 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-29T00:38:51Z Hal Finkel hfinkel@anl.gov 2012-11-29T00:38:51Z urn:sha1:0416bc140fb88b3e5a0d5ce3a278655b1a539324 git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168839 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-26T16:49:56Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-26T16:49:56Z urn:sha1:077cee586eda8b0edcca1ff07e823104eff718e7 InstructionSimplify should be able to simplify A+B==B+A to 'true' but wasn't due to the same logic bug that caused PR14361. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168593 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-22T06:21:31Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-22T06:21:31Z urn: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 2012-11-22T00:43:18Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-22T00:43:18Z urn:sha1:ddf07067bc7ec9897a17352c2db23fb4d1a55db4 Don't try to calculate the alignment of an unsigned type. Fixes PR14371! git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168480 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-21T19:01:53Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-21T19:01:53Z urn:sha1:07d7748544abaaf97123233804a194478ed020b3 Fix PR14361: wrong simplification of A+B==B+A. You may think that the old logic replaced by this patch is equivalent to the new logic, but you'd be wrong, and that's exactly where the bug was. There's a similar bug in instsimplify which manifests itself as instsimplify failing to simplify this, rather than doing it wrong, see next commit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168447 91177308-0d34-0410-b5e6-96231b3b80d8 2012-11-21T18:55:44Z Pawel Wodnicki pawel@32bitmicro.com 2012-11-21T18:55:44Z urn: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