http://llvm.org https://git.amat.us/llvm/atom/lib/Transforms?h=release_33 2013-05-10T18:23:11Z 2013-05-10T18:23:11Z Bill Wendling isanbard@gmail.com 2013-05-10T18:23:11Z urn:sha1:0a3c6b4fcc83c9bc27823de65bd6c0915cebbda0 ------------------------------------------------------------------------ r181397 | nicholas | 2013-05-08 02:00:10 -0700 (Wed, 08 May 2013) | 3 lines Fix a bug in codegenprep where it was losing track of values OptimizeMemoryInst by switching to a ValueMap. Patch by Andrea DiBiagio! ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@181619 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-08T18:13:06Z Bill Wendling isanbard@gmail.com 2013-05-08T18:13:06Z urn:sha1:c7594e48edb1b7a2ec9fc81981e539eac0604905 ------------------------------------------------------------------------ r181286 | arnolds | 2013-05-06 21:37:05 -0700 (Mon, 06 May 2013) | 7 lines LoopVectorize: getConsecutiveVector must respect signed arithmetic We were passing an i32 to ConstantInt::get where an i64 was needed and we must also pass the sign if we pass negatives numbers. The start index passed to getConsecutiveVector must also be signed. Should fix PR15882. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@181455 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T21:21:31Z David Majnemer david.majnemer@gmail.com 2013-05-06T21:21:31Z urn:sha1:8ec23cb07e22198a720c4e151241059cca215c08 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181249 91177308-0d34-0410-b5e6-96231b3b80d8 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 2013-05-06T16:55:50Z Jean-Luc Duprat jduprat@apple.com 2013-05-06T16:55:50Z urn:sha1:c5cf6e536598a3b1e30fce616b771d66a071a54c A * (1 - (uitofp i1 C)) -> select C, 0, A B * (uitofp i1 C) -> select C, B, 0 select C, 0, A + select C, B, 0 -> select C, B, A These come up in code that has been hand-optimized from a select to a linear blend, on platforms where that may have mattered. We want to undo such changes with the following transform: A*(1 - uitofp i1 C) + B*(uitofp i1 C) -> select C, A, B git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181216 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T03:06:36Z Nadav Rotem nrotem@apple.com 2013-05-06T03:06:36Z urn:sha1:37d38b7668f3dd64e2263426c29253ace50865b3 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181178 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T02:39:09Z Nadav Rotem nrotem@apple.com 2013-05-06T02:39:09Z urn:sha1:4ee312bac138a18c39353d4736eb5921532f9624 Thanks Nick Lewycky for pointing this out. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181177 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T01:48:55Z Rafael Espindola rafael.espindola@gmail.com 2013-05-06T01:48:55Z urn:sha1:eaf14786ca3975266ed7041ac242122c02baf1cf We used to disable constant merging not only if a constant is llvm.used, but also if an alias of a constant is llvm.used. This change fixes that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181175 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-05T14:54:52Z Benjamin Kramer benny.kra@googlemail.com 2013-05-05T14:54:52Z urn:sha1:acc47c738d5888f7445275095a174c7f48296449 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181157 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-05T01:54:48Z Arnold Schwaighofer aschwaighofer@apple.com 2013-05-05T01:54:48Z urn:sha1:87defd0924e08dd9c9db51e2fb208f289fa6adf7 Add support for min/max reductions when "no-nans-float-math" is enabled. This allows us to assume we have ordered floating point math and treat ordered and unordered predicates equally. radar://13723044 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181144 91177308-0d34-0410-b5e6-96231b3b80d8