| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 14095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
us to
collapse this:
bool %le(int %A, int %B) {
%c1 = setgt int %A, %B
%tmp = select bool %c1, int 1, int 0
%c2 = setlt int %A, %B
%result = select bool %c2, int -1, int %tmp
%c3 = setle int %result, 0
ret bool %c3
}
into:
bool %le(int %A, int %B) {
%c3 = setle int %A, %B ; <bool> [#uses=1]
ret bool %c3
}
which is handy, because the Java FE makes these sequences all over the place.
This is tested as: test/Regression/Transforms/InstCombine/JavaCompare.ll
llvm-svn: 14086
|
|
|
|
| |
llvm-svn: 14083
|
|
|
|
| |
llvm-svn: 13982
|
|
|
|
| |
llvm-svn: 13930
|
|
|
|
| |
llvm-svn: 13872
|
|
|
|
|
|
| |
to eliminate the wrong type.
llvm-svn: 13855
|
|
|
|
|
|
|
|
|
|
| |
This code hadn't been updated after the "structs with more than 256 elements"
related changes to the GEP instruction. Also it was not handling the
ConstantAggregateZero class.
Now it does!
llvm-svn: 13834
|
|
|
|
| |
llvm-svn: 13823
|
|
|
|
|
|
|
|
| |
Add support for acos/asin/atan. 188.ammp contains three calls to acos with
constant arguments. Constant folding it allows elimination of those 3 calls
and three FP divisions of the results.
llvm-svn: 13821
|
|
|
|
|
|
| |
appended anywhere.
llvm-svn: 13798
|
|
|
|
| |
llvm-svn: 13792
|
|
|
|
| |
llvm-svn: 13754
|
|
|
|
| |
llvm-svn: 13751
|
|
|
|
| |
llvm-svn: 13750
|
|
|
|
| |
llvm-svn: 13749
|
|
|
|
|
|
|
|
|
|
| |
into (X & (C2 << C1)) != (C3 << C1), where the shift may be either left or
right and the compare may be any one.
This triggers 1546 times in 176.gcc alone, as it is a common pattern that
occurs for bitfield accesses.
llvm-svn: 13740
|
|
|
|
|
|
| |
Canonicalize cast X to bool into a setne instruction
llvm-svn: 13736
|
|
|
|
| |
llvm-svn: 13717
|
|
|
|
| |
llvm-svn: 13702
|
|
|
|
|
|
| |
caller was in an SCC.
llvm-svn: 13693
|
|
|
|
| |
llvm-svn: 13692
|
|
|
|
|
|
|
| |
we make the transformation. This allows us to use interprocedural alias
analyses successfully.
llvm-svn: 13691
|
|
|
|
| |
llvm-svn: 13690
|
|
|
|
| |
llvm-svn: 13689
|
|
|
|
|
|
| |
that do not have builtin support for garbage collection.
llvm-svn: 13688
|
|
|
|
|
|
| |
effects as) CloneFunctionInto().
llvm-svn: 13601
|
|
|
|
|
|
|
|
| |
CloneTrace, and because it is primarily an operation on ValueMaps. It
is now a global (non-static) function which can be pulled in using
ValueMapper.h.
llvm-svn: 13600
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add better comments, including a better head-of-file comment.
Prune #includes.
Fix a FIXME that Chris put here by using doInitialization().
Use DEBUG() to print out debug msgs.
Give names to basic blocks inserted by this pass.
Expand tabs.
Use InsertProfilingInitCall() from ProfilingUtils to insert the initialize call.
llvm-svn: 13581
|
|
|
|
| |
llvm-svn: 13565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the size calculation.
This is not something you want to see:
Loop Unroll: F[main] Loop %no_exit Loop Size = 2 Trip Count = 2147483648 - UNROLLING!
The problem was that 2*2147483648 == 0.
Now we get:
Loop Unroll: F[main] Loop %no_exit Loop Size = 2 Trip Count = 2147483648 - TOO LARGE: 4294967296>100
Thanks to some anonymous person playing with the demo page that repeatedly
caused zion to go into swapping land. That's one way to ensure you'll get
a quick bugfix. :)
Testcase here: Transforms/LoopUnroll/2004-05-13-DontUnrollTooMuch.ll
llvm-svn: 13564
|