http://llvm.org https://git.amat.us/llvm/atom/test/Transforms/IndVarSimplify?h=release_32 2012-11-30T03:38:58Z 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-10-26T17:31:43Z Benjamin Kramer benny.kra@googlemail.com 2012-10-26T17:31:43Z urn:sha1:b2b2273ef4b67b7da4c05472095b8b96cc04ca8d The LoopSimplify bug is pretty harmless because the loop goes from unanalyzable to analyzable but the LCSSA bug is very nasty. It only comes into play with a specific order of the LoopPassManager worklist and can cause actual miscompilations, when a SCEV refers to a value that has been replaced with PHI node. SCEVExpander may then insert code into the wrong place, either violating domination or randomly miscompiling stuff. Comes with an extensive test case reduced from the test-suite with bugpoint+SCEVValidator. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166787 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-19T17:53:54Z Benjamin Kramer benny.kra@googlemail.com 2012-10-19T17:53:54Z urn:sha1:7182126b0f3100cfddfbe6939be1a7eaeaf9fd57 This can invalidate the iterators leading to use after frees and crashes. Fixes PR12536. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166291 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-19T16:37:30Z Benjamin Kramer benny.kra@googlemail.com 2012-10-19T16:37:30Z urn:sha1:239fd44f7a68aae4b2e8b6f1738ef9e8fd4ddc01 Just constant fold them so they can't cause any trouble. Fixes PR12627. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166286 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-08T16:39:34Z Micah Villmow villmow@gmail.com 2012-10-08T16:39:34Z urn:sha1:791cfc211a9801002bfda6b3eb4de7e041f04f53 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165403 91177308-0d34-0410-b5e6-96231b3b80d8 2012-10-03T23:59:47Z Jakub Staszak kubastaszak@gmail.com 2012-10-03T23:59:47Z urn:sha1:395c1502a7e6380ec2210ee4be1fdb3128c10528 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165187 91177308-0d34-0410-b5e6-96231b3b80d8 2012-07-18T04:35:10Z Andrew Trick atrick@apple.com 2012-07-18T04:35:10Z urn:sha1:4781d8ee1cd586bf7a569f80e1e49694c93eddd8 Fixes PR13371: indvars pass incorrectly substitutes 'undef' values. I do not like this fix. It's needed until/unless the meaning of undef changes. It attempts to be complete according to the IR spec, but I don't have much confidence in the implementation given the difficulty testing undefined behavior. Worse, this invalidates some of my hard-fought work on indvars and LSR to optimize pointer induction variables. It results benchmark regressions, which I'll track internally. On x86_64 no LTO I see: -3% huffbench -3% 400.perlbench -8% fhourstones My only suggestion for recovering is to change the meaning of undef. If we could trust an arbitrary instruction to produce a some real value that can be manipulated (e.g. incremented) according to non-undef rules, then this case could be easily handled with SCEV. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160421 91177308-0d34-0410-b5e6-96231b3b80d8 2012-07-02T19:09:46Z Chandler Carruth chandlerc@gmail.com 2012-07-02T19:09:46Z urn:sha1:1de43ede8904e08de37f601c9bab0b70f71156e1 another mechanical change accomplished though the power of terrible Perl scripts. I have manually switched some "s to 's to make escaping simpler. While I started this to fix tests that aren't run in all configurations, the massive number of tests is due to a really frustrating fragility of our testing infrastructure: things like 'grep -v', 'not grep', and 'expected failures' can mask broken tests all too easily. Essentially, I'm deeply disturbed that I can change the testsuite so radically without causing any change in results for most platforms. =/ git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159547 91177308-0d34-0410-b5e6-96231b3b80d8 2012-07-02T12:47:22Z Chandler Carruth chandlerc@gmail.com 2012-07-02T12:47:22Z urn: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