http://llvm.org https://git.amat.us/llvm/atom/test/Transforms/LoopRotate?h=release_33 2013-05-06T17:58:18Z 2013-05-06T17:58:18Z Andrew Trick atrick@apple.com 2013-05-06T17:58:18Z urn:sha1:fcf79528da4da87996a936b9e86f669c1f0c1dc6 Test case by Michele Scandale! Fixes PR10293: Load not hoisted out of loop with multiple exits. There are few regressions with this patch, now tracked by rdar:13817079, and a roughly equal number of improvements. The regressions are almost certainly back luck because LoopRotate has very little idea of whether rotation is profitable. Doing better requires a more comprehensive solution. This checkin is a quick fix that lacks generality (PR10293 has a counter-example). But it trivially fixes the case in PR10293 without interfering with other cases, and it does satify the criteria that LoopRotate is a loop canonicalization pass that should avoid heuristics and special cases. I can think of two approaches that would probably be better in the long run. Ultimately they may both make sense. (1) LoopRotate should check that the current header would make a good loop guard, and that the loop does not already has a sufficient guard. The artifical SimplifiedLoopLatch check would be unnecessary, and the design would be more general and canonical. Two difficulties: - We need a strong guarantee that we won't endlessly rotate, so the analysis would need to be precise in order to avoid the SimplifiedLoopLatch precondition. - Analysis like this are usually based on SCEV, which we don't want to rely on. (2) Rotate on-demand in late loop passes. This could even be done by shoving the loop back on the queue after the optimization that needs it. This could work well when we find LICM opportunities in multi-branch loops. This requires some work, and it doesn't really solve the problem of SCEV wanting a loop guard before the analysis. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181230 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-30T02:33:22Z Dmitri Gribenko gribozavr@gmail.com 2012-12-30T02:33:22Z urn:sha1:a6542923b8ad94d791a12d3d5ae3e62a611f0383 This is done to avoid odd test failures, like the one fixed in r171243. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171250 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-30T01:28:40Z Dmitri Gribenko gribozavr@gmail.com 2012-12-30T01:28:40Z urn:sha1:b4912b9dccd7250c372a40ba0734171c6b0f5e9b This is done to avoid odd test failures, like the one fixed in r171243. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171246 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-20T16:04:27Z James Molloy james.molloy@arm.com 2012-12-20T16:04:27Z urn:sha1:67ae13575900e8efd056672987249fd0adbf5e73 Similarly inlining of the function is inhibited, if that would duplicate the call (in particular inlining is still allowed when there is only one callsite and the function has internal linkage). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170704 91177308-0d34-0410-b5e6-96231b3b80d8 2012-09-02T11:57:22Z Benjamin Kramer benny.kra@googlemail.com 2012-09-02T11:57:22Z urn:sha1:7de7078933292b0487f1f39f539bece922e3dde5 We update until we hit a fixpoint. This is probably slow but also slightly simplifies the code. It should also fix the occasional invalid domtrees observed when building with expensive checking. I couldn't find a case where this had a measurable slowdown, but if someone finds a pathological case where it does we may have to find a cleverer way of updating dominators here. Thanks to Duncan for the test case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163091 91177308-0d34-0410-b5e6-96231b3b80d8 2012-08-30T15:42:45Z Benjamin Kramer benny.kra@googlemail.com 2012-08-30T15:42:45Z urn:sha1:86c0d8c92fd36f60fa12cc5a729a42ed403b277d git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162913 91177308-0d34-0410-b5e6-96231b3b80d8 2012-08-30T15:39:42Z Benjamin Kramer benny.kra@googlemail.com 2012-08-30T15:39:42Z urn:sha1:d70846ec1b79162d519620ddf07bcb7a64b65eb5 The old PHI updating code in loop-rotate was replaced with SSAUpdater a while ago, it has no problems with comples PHIs. What had to be fixed is detecting whether a loop was already rotated and updating dominators when multiple exits were present. This change increases overall code size a bit, mostly due to additional loop unrolling opportunities. Passes test-suite and selfhost with -verify-dom-info. Fixes PR7447. Thanks to Andy for the input on the domtree updating code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162912 91177308-0d34-0410-b5e6-96231b3b80d8 2012-07-17T15:43:17Z NAKAMURA Takumi geek4civic@gmail.com 2012-07-17T15:43:17Z urn:sha1:f30135c519a983513b1a9cb4c96409cda4c5b39e It began choking since Chandler's r159547, possibly due to improper expression on grep from TclParser to ShParser. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160367 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-04-07T19:22:18Z Chandler Carruth chandlerc@gmail.com 2012-04-07T19:22:18Z urn:sha1:c0d18b669674d3b173e6a3eca6ada98871bb808f speculate. Without this, loop rotate (among many other places) would suddenly stop working in the presence of debug info. I found this looking at loop rotate, and have augmented its tests with a reduction out of a very hot loop in yacr2 where failing to do this rotation costs sometimes more than 10% in runtime performance, perturbing numerous downstream optimizations. This should have no impact on performance without debug info, but the change in performance when debug info is enabled can be extreme. As a consequence (and this how I got to this yak) any profiling of performance problems should be treated with deep suspicion -- they may have been wildly innacurate of debug info was enabled for profiling. =/ Just a heads up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154263 91177308-0d34-0410-b5e6-96231b3b80d8