| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 14649
|
|
|
|
|
|
| |
the first is a zero, we should leave it alone.
llvm-svn: 14648
|
|
|
|
|
|
|
| |
Don't touch GEPs for which DecomposeArrayRef is not going to do anything
special (e.g., < 2 indices, or 2 indices and the last one is a constant.)
llvm-svn: 14647
|
|
|
|
| |
llvm-svn: 14640
|
|
|
|
| |
llvm-svn: 14638
|
|
|
|
|
|
|
| |
Also, remove X % -1 = 0, because it's not true for unsigneds, and the
signed case is superceeded by this new handling.
llvm-svn: 14637
|
|
|
|
| |
llvm-svn: 14622
|
|
|
|
| |
llvm-svn: 14587
|
|
|
|
| |
llvm-svn: 14584
|
|
|
|
| |
llvm-svn: 14560
|
|
|
|
| |
llvm-svn: 14541
|
|
|
|
| |
llvm-svn: 14478
|
|
|
|
| |
llvm-svn: 14460
|
|
|
|
|
|
| |
and are a maintenence burden. Nuke nuke nuke
llvm-svn: 14457
|
|
|
|
| |
llvm-svn: 14443
|
|
|
|
|
|
|
|
| |
needs.
Contributed by Vladimir Prus!
llvm-svn: 14399
|
|
|
|
| |
llvm-svn: 14369
|
|
|
|
|
|
|
| |
Second, disable substitution of quadratic addrec expressions to avoid putting
multiplies in loops!
llvm-svn: 14358
|
|
|
|
| |
llvm-svn: 14348
|
|
|
|
| |
llvm-svn: 14340
|
|
|
|
| |
llvm-svn: 14325
|
|
|
|
|
|
|
|
|
|
|
| |
since May 1st. In this code, the pred iterator was being invalidated sometimes
causing the wrong entries to be added to PHI nodes.
The fix for this is to defererence and safe the *PI value before we hack on
branch instructions, which changes use/def chains, which SOMETIMES invalidates
the iterator.
llvm-svn: 14278
|
|
|
|
|
|
| |
breaking the build on sparc is not acceptable.
llvm-svn: 14277
|
|
|
|
|
|
|
| |
of ConstantInt objects in memory used to determine which order arguments
were added in in some cases.
llvm-svn: 14276
|
|
|
|
| |
llvm-svn: 14262
|
|
|
|
|
|
| |
relative location of Function objects in memory.
llvm-svn: 14260
|
|
|
|
|
|
|
| |
Fix another non-deterministic behavior, this one should actually speed up the
code though as it was doing silly things.
llvm-svn: 14258
|
|
|
|
|
|
|
|
| |
horrible code
can go away
llvm-svn: 14254
|
|
|
|
|
|
| |
into valiantly trying to compile stuff on freebsd.
llvm-svn: 14251
|
|
|
|
| |
llvm-svn: 14249
|
|
|
|
|
|
|
| |
was processing blocks in whatever order they happened to end up in the
dominator tree data structure. Force an ordering.
llvm-svn: 14248
|
|
|
|
| |
llvm-svn: 14247
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-deterministic things like the ordering of blocks in the dominance
frontier of a BB. Unfortunately, I don't know of a better way to solve
this problem than to explicitly sort the BB's in function-order before
processing them. This is guaranteed to slow the pass down a bit, but
is absolutely necessary to get usable diffs between two different tools
executing the mem2reg or scalarrepl pass.
Before this, bazillions of spurious diff failures occurred all over the
place due to the different order of processing PHIs:
- %tmp.111 = getelementptr %struct.Connector_struct* %upcon.0.0, uint 0, uint 0
+ %tmp.111 = getelementptr %struct.Connector_struct* %upcon.0.1, uint 0, uint 0
Now, the diffs match.
llvm-svn: 14244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nondeterministic results that depend on where these objects land in memory.
Instead, sort by the value of the constant, which is stable.
Before this patch, the -simplifycfg pass run from two different compilers
could cause different code to be generated, though it was semantically the
same:
@@ -12258,8 +12258,8 @@
%s_addr.1 = phi sbyte* [ %s, %entry ], [ %inc.0, %no_exit ] ; <sbyte*> [#uses=5]
%tmp.1 = load sbyte* %s_addr.1 ; <sbyte> [#uses=1]
switch sbyte %tmp.1, label %no_exit [
- sbyte 0, label %loopexit
sbyte 46, label %loopexit
+ sbyte 0, label %loopexit
]
We need to stomp all of this stuff out.
llvm-svn: 14243
|
|
|
|
|
|
| |
invalidated out from under us. This bug goes back to revision 1.1: scary.
llvm-svn: 14242
|
|
|
|
|
|
| |
occurs due to unordered comparison macros in math.h
llvm-svn: 14221
|
|
|
|
|
|
|
|
|
| |
things from happening due to
declare bool %llvm.isunordered(double, double)
declare bool %llvm.isunordered(float, float)
llvm-svn: 14219
|
|
|
|
| |
llvm-svn: 14206
|
|
|
|
|
|
| |
PR371
llvm-svn: 14203
|
|
|
|
| |
llvm-svn: 14201
|
|
|
|
|
|
| |
Delete two functions that are now methods on the Type class
llvm-svn: 14200
|
|
|
|
| |
llvm-svn: 14196
|
|
|
|
| |
llvm-svn: 14192
|
|
|
|
| |
llvm-svn: 14186
|
|
|
|
|
|
|
|
| |
is write an autoconf macro that checks whether __isnan or isnan actually works
**using the C++ compiler after #include <cmath>**, instead of doing it the easy
way with AC_CHECK_FUNCS().
llvm-svn: 14171
|
|
|
|
| |
llvm-svn: 14168
|
|
|
|
| |
llvm-svn: 14150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
186.crafty, fhourstones and 132.ijpeg.
Bugpoint makes really nasty miscompilations embarassingly easy to find. It
narrowed it down to the instcombiner and this testcase (from fhourstones):
bool %l7153_l4706_htstat_loopentry_2E_4_no_exit_2E_4(int* %i, [32 x int]* %works, int* %tmp.98.out) {
newFuncRoot:
%tmp.96 = load int* %i ; <int> [#uses=1]
%tmp.97 = getelementptr [32 x int]* %works, long 0, int %tmp.96 ; <int*> [#uses=1]
%tmp.98 = load int* %tmp.97 ; <int> [#uses=2]
%tmp.99 = load int* %i ; <int> [#uses=1]
%tmp.100 = and int %tmp.99, 7 ; <int> [#uses=1]
%tmp.101 = seteq int %tmp.100, 7 ; <bool> [#uses=2]
%tmp.102 = cast bool %tmp.101 to int ; <int> [#uses=0]
br bool %tmp.101, label %codeRepl4.exitStub, label %codeRepl3.exitStub
codeRepl4.exitStub: ; preds = %newFuncRoot
store int %tmp.98, int* %tmp.98.out
ret bool true
codeRepl3.exitStub: ; preds = %newFuncRoot
store int %tmp.98, int* %tmp.98.out
ret bool false
}
... which only has one combination performed on it:
$ llvm-as < t.ll | opt -instcombine -debug | llvm-dis
IC: Old = %tmp.101 = seteq int %tmp.100, 7 ; <bool> [#uses=1]
New = setne int %tmp.100, 0 ; <bool>:<badref> [#uses=0]
IC: MOD = br bool %tmp.101, label %codeRepl3.exitStub, label %codeRepl4.exitStub
IC: MOD = %tmp.97 = getelementptr [32 x int]* %works, uint 0, int %tmp.96 ; <int*> [#uses=1]
It doesn't get much better than this. :)
llvm-svn: 14109
|
|
|
|
| |
llvm-svn: 14108
|
|
|
|
| |
llvm-svn: 14107
|