emscripten-fastcomp/lib/Transforms/Scalar, branch masterLLVM with the emscripten fastcomp javascript backendhttps://git.amat.us/emscripten-fastcomp/atom/lib/Transforms/Scalar?h=master2013-05-10T18:23:11ZMerging r181397:2013-05-10T18:23:11ZBill Wendlingisanbard@gmail.com2013-05-10T18:23:11Zurn: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
Rotate multi-exit loops even if the latch was simplified.2013-05-06T17:58:18ZAndrew Trickatrick@apple.com2013-05-06T17:58:18Zurn: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
Decompose GVN::processNonLocalLoad() (about 400 LOC) into smaller helper functions. No function change. 2013-05-03T19:17:26ZShuxin Yangshuxin.llvm@gmail.com2013-05-03T19:17:26Zurn:sha1:968d689ec30a0df63d252b8193664e01944edb8b
This function consists of following steps:
1. Collect dependent memory accesses.
2. Analyze availability.
3. Perform fully redundancy elimination, or
4. Perform PRE, depending on the availability
Step 2, 3 and 4 are now moved to three helper routines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181047 91177308-0d34-0410-b5e6-96231b3b80d8
[GV] Remove dead code which is really difficult to decipher.2013-05-02T21:14:31ZShuxin Yangshuxin.llvm@gmail.com2013-05-02T21:14:31Zurn:sha1:556dd3a9a9068337a84e3ba32253a10cd1ab67dc
Actually it took me couple of hours trying to make sense of them and
only to find they are dead code. I guess the original author used
"allSingleSucc" to indicate if there are any critial edge emanating
from some blocks, and tried to perform code motion (actually speculation)
in the presence of these critical edges; but later on he/she changed mind
and decided to perform edge-splitting first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180951 91177308-0d34-0410-b5e6-96231b3b80d8
This patch breaks up Wrap.h so that it does not have to include all of 2013-05-01T20:59:00ZFilip Pizlofpizlo@apple.com2013-05-01T20:59:00Zurn:sha1:40be1e85665d10f5444186f0e7106e368dd735b8
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8
SROA: Generate selects instead of shuffles when blending values because this is the cannonical form.2013-05-01T19:53:30ZNadav Rotemnrotem@apple.com2013-05-01T19:53:30Zurn:sha1:fee6969463d455201a5179620ccd8c3171effaa6
Shuffles are more difficult to lower and we usually don't touch them, while we do optimize selects more often.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180875 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a XOR reassociation bug. 2013-04-27T18:02:12ZShuxin Yangshuxin.llvm@gmail.com2013-04-27T18:02:12Zurn:sha1:4d4c54d29ff911f59fe2be1a31331dbcbb741f5f
When Reassociator optimize "(x | C1)" ^ "(X & C2)", it may swap the two
subexpressions, however, it forgot to swap cached constants (of C1 and C2)
accordingly.
rdar://13739160
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180676 91177308-0d34-0410-b5e6-96231b3b80d8
Move C++ code out of the C headers and into either C++ headers2013-04-22T22:47:22ZEric Christopherechristo@gmail.com2013-04-22T22:47:22Zurn:sha1:3e39731e88f2d4f597cebc74388fd6650ca4f604
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180063 91177308-0d34-0410-b5e6-96231b3b80d8
Clarify that llvm.used can contain aliases.2013-04-22T14:58:02ZRafael Espindolarafael.espindola@gmail.com2013-04-22T14:58:02Zurn:sha1:cde25b435a907e7741da0c0d18953850936277c4
Also add a check for llvm.used in the verifier and simplify clients now that
they can assume they have a ConstantArray.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180019 91177308-0d34-0410-b5e6-96231b3b80d8
SROA: Don't crash on a select with two identical operands.2013-04-21T17:48:39ZBenjamin Kramerbenny.kra@googlemail.com2013-04-21T17:48:39Zurn:sha1:d81a0dee5b7df712c584e2a3e556ff2f0677e9df
This is an edge case that can happen if we modify a chain of multiple selects.
Update all operands in that case and remove the assert. PR15805.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179982 91177308-0d34-0410-b5e6-96231b3b80d8