http://llvm.org https://git.amat.us/llvm/atom/test/Transforms/SCCP?h=release_32 2012-11-08T20:34:25Z 2012-11-08T20:34:25Z NAKAMURA Takumi geek4civic@gmail.com 2012-11-08T20:34:25Z urn:sha1:562b1d883f304e52b237e0af2ff7e4a9e02100cd git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167595 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 2012-04-27T17:50:22Z Dan Gohman gohman@apple.com 2012-04-27T17:50:22Z urn:sha1:03e091f0b5f43beee12170efc00bbab86ffeb0dc properly with how the code handles all-undef PHI nodes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155721 91177308-0d34-0410-b5e6-96231b3b80d8 2012-04-27T07:59:20Z NAKAMURA Takumi geek4civic@gmail.com 2012-04-27T07:59:20Z urn:sha1:d213ee764341b5bf6664469a5404fe19c9732828 It broke stage2 build. stage1/clang sometimes crashed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155699 91177308-0d34-0410-b5e6-96231b3b80d8 2012-04-27T00:54:36Z Dan Gohman gohman@apple.com 2012-04-27T00:54:36Z urn:sha1:97b44f9b8026fce47c1c882347f88af91c6e74c1 instead of getAggregateElement. This has the advantage of being more consistent and allowing higher-level constant folding to procede even if an inner extract element cannot be folded. Make ConstantFoldInstruction call ConstantFoldConstantExpression on the instruction's operands, making it more consistent with ConstantFoldConstantExpression itself. This makes sure that ConstantExprs get TargetData-aware folding before being handed off as operands for further folding. This causes more expressions to be folded, but due to a known shortcoming in constant folding, this currently has the side effect of stripping a few more nuw and inbounds flags in the non-targetdata side of constant-fold-gep.ll. This is mostly harmless. This fixes rdar://11324230. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155682 91177308-0d34-0410-b5e6-96231b3b80d8 2012-02-16T06:28:33Z Eli Bendersky eli.bendersky@intel.com 2012-02-16T06:28:33Z urn:sha1:0f0c411079cd21bb3a81a1b70bf8c67539a16c22 Patch reviewed by Daniel Dunbar. It will be followed by additional cleanup patches. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150664 91177308-0d34-0410-b5e6-96231b3b80d8 2012-01-31T02:09:07Z Bill Wendling isanbard@gmail.com 2012-01-31T02:09:07Z urn:sha1:1fe1adeeba913d35db8466eb67eebe7228d1f996 There was always the current EH. -- Ministry of Truth git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149335 91177308-0d34-0410-b5e6-96231b3b80d8 2011-12-12T11:59:10Z Chandler Carruth chandlerc@gmail.com 2011-12-12T11:59:10Z urn:sha1:ddbc274169ed4ee0e0ac32ed194b925a180202fe I followed three heuristics for deciding whether to set 'true' or 'false': - Everything target independent got 'true' as that is the expected common output of the GCC builtins. - If the target arch only has one way of implementing this operation, set the flag in the way that exercises the most of codegen. For most architectures this is also the likely path from a GCC builtin, with 'true' being set. It will (eventually) require lowering away that difference, and then lowering to the architecture's operation. - Otherwise, set the flag differently dependending on which target operation should be tested. Let me know if anyone has any issue with this pattern or would like specific tests of another form. This should allow the x86 codegen to just iteratively improve as I teach the backend how to differentiate between the two forms, and everything else should remain exactly the same. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146370 91177308-0d34-0410-b5e6-96231b3b80d8 2011-11-11T01:16:15Z Eli Friedman eli.friedman@gmail.com 2011-11-11T01:16:15Z urn:sha1:b80f778bd315e5c37b987c3203c6d40bd9c3bfe6 lead to it trying to re-mark a value marked as a constant with a different value. It also appears to trigger very rarely. Fixes PR11357. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144352 91177308-0d34-0410-b5e6-96231b3b80d8