c48bbe7170
Add extra CHECK to make sure that 'or' instruction was replaced.
...
Also add an assert to avoid confusion in the code where is known that C1 <= C2.
llvm-svn: 171310
2012-12-31 18:26:42 +00:00
ea2b9b9d67
Transform (A == C1 || A == C2) into (A & ~(C1 ^ C2)) == C1
...
if C1 and C2 differ only with one bit.
Fixes PR14708.
llvm-svn: 171270
2012-12-31 00:34:55 +00:00
5917f4c715
Transform (x&C)>V into (x&C)!=0 where possible
...
When the least bit of C is greater than V, (x&C) must be greater than V
if it is not zero, so the comparison can be simplified.
Although this was suggested in Target/X86/README.txt, it benefits any
architecture with a directly testable form of AND.
Patch by Kevin Schoedel
llvm-svn: 170576
2012-12-19 19:47:13 +00:00
38d2b2442f
Revert r170020, "Simplify negated bit test", for now.
...
This assumes (1 << n) is always not zero. Consider n is greater than word size.
Although I know it is undefined, this transforms undefined behavior hidden.
This led clang unexpected behavior with some failures. I will investigate to fix undefined shl in clang.
llvm-svn: 170128
2012-12-13 14:28:16 +00:00
5226aa94ce
Simplify negated bit test
...
llvm-svn: 170020
2012-12-12 20:48:54 +00:00
1d3acddf0e
Fix PR14361: wrong simplification of A+B==B+A. You may think that the old logic
...
replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was. There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.
llvm-svn: 168181
2012-11-16 18:55:49 +00:00
8b8a76974f
InstCombine: Turn (zext A) == (B & (1<<X)-1) into A == (trunc B), narrowing the compare.
...
This saves a cast, and zext is more expensive on platforms with subreg support
than trunc is. This occurs in the BSD implementation of memchr(3), see PR12750.
On the synthetic benchmark from that bug stupid_memchr and bsd_memchr have the
same performance now when not inlining either function.
stupid_memchr: 323.0us
bsd_memchr: 321.0us
memchr: 479.0us
where memchr is the llvm-gcc compiled bsd_memchr from osx lion's libc. When
inlining is enabled bsd_memchr still regresses down to llvm-gcc memchr time,
I haven't fully understood the issue yet, something is grossly mangling the
loop after inlining.
llvm-svn: 158297
2012-06-10 20:35:00 +00:00
3db143ea8c
Reinstate the optimization from r151449 with a fix to not turn 'gep %x' into
...
'gep null' when the icmp predicate is unsigned (or is signed without inbounds).
llvm-svn: 151467
2012-02-26 02:09:49 +00:00
7bbd72da46
Roll these back to r151448 until I figure out how they're breaking
...
MultiSource/Applications/lua.
llvm-svn: 151463
2012-02-25 23:01:19 +00:00
51f2be8bff
Teach instsimplify to be more aggressive when analyzing comparisons of pointers
...
by using llvm::isIdentifiedObject. Also teach it to handle GEPs that have
the same base pointer and constant operands. Fixes PR11238!
llvm-svn: 151449
2012-02-25 19:07:42 +00:00
6ee8690aa5
InstCombine: Don't transform a signed icmp of two GEPs into a signed compare of the indices.
...
This transformation is not safe in some pathological cases (signed icmp of pointers should be an
extremely rare thing, but it's valid IR!). Add an explanatory comment.
Kudos to Duncan for pointing out this edge case (and not giving up explaining it until I finally got it).
llvm-svn: 151055
2012-02-21 13:31:09 +00:00
a00c5c451a
Test case for r150978.
...
llvm-svn: 150979
2012-02-20 19:00:28 +00:00
7adb189538
InstCombine: When comparing two GEPs that were derived from the same base pointer but use different types, expand the offset calculation and to the compare on the offset if profitable.
...
This came up in SmallVector code.
llvm-svn: 150962
2012-02-20 15:07:47 +00:00
bb893fea6b
Add r149110 back with a fix for when the vector and the int have the same
...
width.
llvm-svn: 149151
2012-01-27 23:33:07 +00:00
a4062624d1
Revert r149110 and add a testcase that was crashing since that revision.
...
Unfortunately I also had to disable constant-pool-sharing.ll the code it tests has been
updated to use the IL logic.
llvm-svn: 149148
2012-01-27 22:42:48 +00:00
111d6ee655
enhance constant folding to be able to constant fold bitcast of
...
ConstantVector's to integer type.
llvm-svn: 149110
2012-01-27 01:44:03 +00:00
aca1885695
FileCheck hygiene.
...
llvm-svn: 147580
2012-01-05 00:43:34 +00:00
fdddc27143
Improved fix for abs(val) != 0 to check other similar case. Also fixed style issues and confusing comment
...
llvm-svn: 145618
2011-12-01 19:13:26 +00:00
3b7f35bf08
Removed use of grep from test and moved it to be with other icmp tests
...
llvm-svn: 145570
2011-12-01 04:35:26 +00:00
9eca5feff1
PR10267: Don't combine an equality compare with an AND into an inequality compare when the AND has more than one use.
...
This can pessimize code, inequalities are generally more expensive.
llvm-svn: 134379
2011-07-04 20:16:36 +00:00
c970849ea0
InstCombine: Fold A-b == C --> b == A-C if A and C are constants.
...
The backend already knew this trick.
llvm-svn: 132915
2011-06-13 15:24:24 +00:00
91f914ce21
InstCombine: Shrink ((zext X) & C1) == C2 to fold away the cast if the "zext" and the "and" have one use.
...
llvm-svn: 132897
2011-06-12 22:48:00 +00:00
8a20e66926
PR9838: Fix transform introduced in r127064 to not trigger when only one side of the icmp is an exact shift.
...
llvm-svn: 130954
2011-05-05 21:59:18 +00:00
1b06c71668
Transform: "icmp eq (trunc (lshr(X, cst1)), cst" to "icmp (and X, mask), cst"
...
when X has multiple uses. This is useful for exposing secondary optimizations,
but the X86 backend isn't ready for this when X has a single use. For example,
this can disable load folding.
This is inching towards resolving PR6627.
llvm-svn: 130238
2011-04-26 20:18:20 +00:00
1885d21700
Fix mistyped CHECK lines.
...
llvm-svn: 127366
2011-03-09 22:07:31 +00:00
ac55c79dd6
Tweak this test. We can analyze what happens and show that we still do the
...
right thing, instead of merely being unable to analyze and the transform
doesn't occur.
llvm-svn: 127149
2011-03-07 02:10:18 +00:00
e467979d0a
Add more analysis of the sign bit of an srem instruction. If the LHS is negative
...
then the result could go either way. If it's provably positive then so is the
srem. Fixes PR9343 #7 !
llvm-svn: 127146
2011-03-07 01:50:10 +00:00
92db8e8e39
ConstantInt has some getters which return ConstantInt's or ConstantVector's of
...
the value splatted into every element. Extend this to getTrue and getFalse which
by providing new overloads that take Types that are either i1 or <N x i1>. Use
it in InstCombine to add vector support to some code, fixing PR8469!
llvm-svn: 127116
2011-03-06 03:36:19 +00:00
9719a719c7
Thread comparisons over udiv/sdiv/ashr/lshr exact and lshr nuw/nsw whenever
...
possible. This goes into instcombine and instsimplify because instsimplify
doesn't need to check hasOneUse since it returns (almost exclusively) constants.
This fixes PR9343 #4 #5 and #8 !
llvm-svn: 127064
2011-03-05 05:19:11 +00:00
25cc338d88
Try once again to optimize "icmp (srem X, Y), Y" by turning the comparison into
...
true/false or "icmp slt/sge Y, 0".
llvm-svn: 127063
2011-03-05 04:28:48 +00:00
8e3a79da9f
Fold "icmp pred (srem X, Y), Y" like we do for urem. Handle signed comparisons
...
in the urem case, though not the other way around. This is enough to get #3 from
PR9343!
llvm-svn: 126991
2011-03-04 10:06:52 +00:00
66f4f22f7b
srem doesn't actually have the same resulting sign as its numerator, you could
...
also have a zero when numerator = denominator. Reverts parts of r126635 and
r126637.
llvm-svn: 126644
2011-02-28 09:17:39 +00:00
174a705497
Teach InstCombine to fold "(shr exact X, Y) == 0" --> X == 0, fixing #1 from
...
PR9343.
llvm-svn: 126643
2011-02-28 08:31:40 +00:00
6b445419b0
The sign of an srem instruction is the sign of its dividend (the first
...
argument), regardless of the divisor. Teach instcombine about this and fix
test7 in PR9343!
llvm-svn: 126635
2011-02-28 06:20:05 +00:00
84653b3674
Add some transforms of the kind X-Y>X -> 0>Y which are valid when there is no
...
overflow. These subsume some existing equality transforms, so zap those.
llvm-svn: 125843
2011-02-18 16:25:37 +00:00
e522001171
Transform "A + B >= A + C" into "B >= C" if the adds do not wrap. Likewise for some
...
variations (some of these were already present so I unified the code). Spotted by my
auto-simplifier as occurring a lot.
llvm-svn: 125734
2011-02-17 07:46:37 +00:00
d86ded17ad
implement the first part of PR8882: when lowering an inbounds
...
gep to explicit addressing, we know that none of the intermediate
computation overflows.
This could use review: it seems that the shifts certainly wouldn't
overflow, but could the intermediate adds overflow if there is a
negative index?
Previously the testcase would instcombine to:
define i1 @test(i64 %i) {
%p1.idx.mask = and i64 %i, 4611686018427387903
%cmp = icmp eq i64 %p1.idx.mask, 1000
ret i1 %cmp
}
now we get:
define i1 @test(i64 %i) {
%cmp = icmp eq i64 %i, 1000
ret i1 %cmp
}
llvm-svn: 125271
2011-02-10 07:11:16 +00:00
206b065afb
merge two tests.
...
llvm-svn: 125195
2011-02-09 17:06:41 +00:00
d490c2d2ae
Fix a random missed optimization by making InstCombine more aggressive when determining which bits are demanded by
...
a comparison against a constant.
llvm-svn: 123203
2011-01-11 00:36:45 +00:00
e5afa15b77
duncan's spider sense was right, I completely reversed the condition
...
on this instcombine xform. This fixes a miscompilation of 403.gcc.
llvm-svn: 119988
2010-11-23 02:42:04 +00:00
f7e896138e
optimize:
...
void a(int x) { if (((1<<x)&8)==0) b(); }
into "x != 3", which occurs over 100 times in 403.gcc but in no
other program in llvm-test.
llvm-svn: 119922
2010-11-21 06:44:42 +00:00
e697a6f24f
Constant fold x == undef to undef.
...
llvm-svn: 107074
2010-06-28 21:30:07 +00:00
3afc0721c7
fix incorrect folding of icmp with undef, PR6481.
...
llvm-svn: 97659
2010-03-03 19:46:03 +00:00
94eb4b285b
fix PR6195, a bug constant folding scalar -> vector compares.
...
llvm-svn: 94997
2010-02-01 20:04:40 +00:00
ffbd02829c
enhance x-(-A) -> x+A to preserve NUW/NSW.
...
Use the presence of NSW/NUW to fold "icmp (x+cst), x" to a constant in
cases where it would otherwise be undefined behavior.
Surprisingly (to me at least), this triggers hundreds of the times in
a few benchmarks: lencode, ldecode, and 466.h264ref seem to *really*
like this.
llvm-svn: 91812
2009-12-21 04:04:05 +00:00
900ce231f9
Optimize all cases of "icmp (X+Cst), X" to something simpler. This triggers
...
a bunch in lencode, ldecod, spass, 176.gcc, 252.eon, among others. It is
also the first part of PR5822
llvm-svn: 91811
2009-12-21 03:19:28 +00:00
d18b455086
convert to filecheck
...
llvm-svn: 91810
2009-12-21 03:11:05 +00:00
406cb75c6b
simplify a transformation by making it more general.
...
llvm-svn: 83792
2009-10-11 21:22:21 +00:00
72a13d2476
Use opt -S instead of piping bitcode output through llvm-dis.
...
llvm-svn: 81257
2009-09-08 22:34:10 +00:00
9737a63ed8
Change these tests to feed the assembly files to opt directly, instead
...
of using llvm-as, now that opt supports this.
llvm-svn: 81226
2009-09-08 16:50:01 +00:00
64b5842986
fix PR4837, some bugs folding vector compares. These
...
return a vector of i1, not i1 itself.
llvm-svn: 80761
2009-09-02 05:12:37 +00:00
f50aa6ae5c
Implement rdar://6480391, extending of equality icmp's to avoid a truncation.
...
I noticed this in the code compiled for a routine using std::map, which produced
this code:
%25 = tail call i32 @memcmp(i8* %24, i8* %23, i32 6) nounwind readonly
%.lobit.i = lshr i32 %25, 31 ; <i32> [#uses=1]
%tmp.i = trunc i32 %.lobit.i to i8 ; <i8> [#uses=1]
%toBool = icmp eq i8 %tmp.i, 0 ; <i1> [#uses=1]
br i1 %toBool, label %bb3, label %bb4
which compiled to:
call L_memcmp$stub
shrl $31, %eax
testb %al, %al
jne LBB1_11 ##
with this change, we compile it to:
call L_memcmp$stub
testl %eax, %eax
js LBB1_11
This triggers all the time in common code, with patters like this:
%169 = and i32 %ply, 1 ; <i32> [#uses=1]
%170 = trunc i32 %169 to i8 ; <i8> [#uses=1]
%toBool = icmp ne i8 %170, 0 ; <i1> [#uses=1]
%7 = lshr i32 %6, 24 ; <i32> [#uses=1]
%9 = trunc i32 %7 to i8 ; <i8> [#uses=1]
%10 = icmp ne i8 %9, 0 ; <i1> [#uses=1]
etc
llvm-svn: 61985
2009-01-09 07:47:06 +00:00
91948d4cad
For PR1319:
...
Upgrade tests to work with new llvm.exp version of llvm_runtest.
llvm-svn: 36013
2007-04-14 20:13:02 +00:00
81f14c63da
sext of compares.
...
llvm-svn: 35892
2007-04-11 06:57:54 +00:00
764ec15b3f
new testcase
...
llvm-svn: 35889
2007-04-11 06:52:24 +00:00
Jakub Staszak