http://llvm.org https://git.amat.us/llvm/atom/test/Transforms/LoopStrengthReduce/X86?h=release_33 2013-02-09T01:11:01Z 2013-02-09T01:11:01Z Andrew Trick atrick@apple.com 2013-02-09T01:11:01Z urn:sha1:6050edfe3e66ac45dbfaee72422b332ecaabb2ae Handle chains in which the same offset is used for both loads and stores to the same array. Fixes rdar://11410078. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174789 91177308-0d34-0410-b5e6-96231b3b80d8 2013-01-07T14:41:08Z Chandler Carruth chandlerc@gmail.com 2013-01-07T14:41:08Z urn:sha1:e4ba75f43e2ab1480d119d2d4eb878256274e0fb TargetTransformInfo rather than TargetLowering, removing one of the primary instances of the layering violation of Transforms depending directly on Target. This is a really big deal because LSR used to be a "special" pass that could only be tested fully using llc and by looking at the full output of it. It also couldn't run with any other loop passes because it had to be created by the backend. No longer is this true. LSR is now just a normal pass and we should probably lift the creation of LSR out of lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done this, or updated all of the tests to use opt and a triple, because I suspect someone more familiar with LSR would do a better job. This change should be essentially without functional impact for normal compilations, and only change behvaior of targetless compilations. The conversion required changing all of the LSR code to refer to the TTI interfaces, which fortunately are very similar to TargetLowering's interfaces. However, it also allowed us to *always* expect to have some implementation around. I've pushed that simplification through the pass, and leveraged it to simplify code somewhat. It required some test updates for one of two things: either we used to skip some checks altogether but now we get the default "no" answer for them, or we used to have no information about the target and now we do have some. I've also started the process of removing AddrMode, as the TTI interface doesn't use it any longer. In some cases this simplifies code, and in others it adds some complexity, but I think it's not a bad tradeoff even there. Subsequent patches will try to clean this up even further and use other (more appropriate) abstractions. Yet again, almost all of the formatting changes brought to you by clang-format. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171735 91177308-0d34-0410-b5e6-96231b3b80d8 2012-08-07T09:45:24Z Chandler Carruth chandlerc@gmail.com 2012-08-07T09:45:24Z urn:sha1:e6450dc2afc18531bf9b70180a9f67376d9f00c7 Previously, MBP essentially aligned every branch target it could. This bloats code quite a bit, especially non-looping code which has no real reason to prefer aligned branch targets so heavily. As Andy said in review, it's still a bit odd to do this without a real cost model, but this at least has much more plausible heuristics. Fixes PR13265. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161409 91177308-0d34-0410-b5e6-96231b3b80d8 2012-05-22T17:39:59Z Andrew Trick atrick@apple.com 2012-05-22T17:39:59Z urn:sha1:3de8ad8bf9081fcb7ec0600fd2a8d1ce809f556d Fixes PR12898: SCEVExpander crash. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157263 91177308-0d34-0410-b5e6-96231b3b80d8 2012-04-16T13:49:17Z Chandler Carruth chandlerc@gmail.com 2012-04-16T13:49:17Z urn:sha1:9e67db4af13abb967cae5858502207a43d26bf84 This is mostly to test the waters. I'd like to get results from FNT build bots and other bots running on non-x86 platforms. This feature has been pretty heavily tested over the last few months by me, and it fixes several of the execution time regressions caused by the inlining work by preventing inlining decisions from radically impacting block layout. I've seen very large improvements in yacr2 and ackermann benchmarks, along with the expected noise across all of the benchmark suite whenever code layout changes. I've analyzed all of the regressions and fixed them, or found them to be impossible to fix. See my email to llvmdev for more details. I'd like for this to be in 3.1 as it complements the inliner changes, but if any failures are showing up or anyone has concerns, it is just a flag flip and so can be easily turned off. I'm switching it on tonight to try and get at least one run through various folks' performance suites in case SPEC or something else has serious issues with it. I'll watch bots and revert if anything shows up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154816 91177308-0d34-0410-b5e6-96231b3b80d8 2012-03-25T09:02:19Z Eli Bendersky eli.bendersky@intel.com 2012-03-25T09:02:19Z urn:sha1:cc85160672e3b2d5ec363cc4e151e5b944a60454 * Removed test/lib/llvm.exp - it is no longer needed * Deleted the dg.exp reading code from test/lit.cfg. There are no dg.exp files left in the test suite so this code is no longer required. test/lit.cfg is now much shorter and clearer * Removed a lot of duplicate code in lit.local.cfg files that need access to the root configuration, by adding a "root" attribute to the TestingConfig object. This attribute is dynamically computed to provide the same information as was previously provided by the custom getRoot functions. * Documented the config.root attribute in docs/CommandGuide/lit.pod git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153408 91177308-0d34-0410-b5e6-96231b3b80d8 2012-03-10T19:03:51Z Andrew Trick atrick@apple.com 2012-03-10T19:03:51Z urn:sha1:644f191d31d45d2c281dfa2a7bfba955f8928348 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152502 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-20T21:21:27Z Andrew Trick atrick@apple.com 2012-01-20T21:21:27Z urn:sha1:a44919ef4574621a64817dfb85cbf68ee4ebf7a8 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148571 91177308-0d34-0410-b5e6-96231b3b80d8 2012-01-20T07:41:13Z Andrew Trick atrick@apple.com 2012-01-20T07:41:13Z urn:sha1:b5c26ef9da16052597d59a412eaae32098aa1be0 LSR has gradually been improved to more aggressively reuse existing code, particularly existing phi cycles. This exposed problems with the SCEVExpander's sloppy treatment of its insertion point. I applied some rigor to the insertion point problem that will hopefully avoid an endless bug cycle in this area. Changes: - Always used properlyDominates to check safe code hoisting. - The insertion point provided to SCEV is now considered a lower bound. This is usually a block terminator or the use itself. Under no cirumstance may SCEVExpander insert below this point. - LSR is reponsible for finding a "canonical" insertion point across expansion of different expressions. - Robust logic to determine whether IV increments are in "expanded" form and/or can be safely hoisted above some insertion point. Fixes PR11783: SCEVExpander assert. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148535 91177308-0d34-0410-b5e6-96231b3b80d8