| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
offset accumulation to use a boring APInt instead of ConstantExprs.
I didn't go all the way to an 'int64_t' because I wanted APInt to handle
any magic required to properly wrap the arithmetic when the pointer
width is <64 bits. If there is a significant penalty from using APInt
here, first off WTF, and secondly let me know and I'll do the math by
hand.
I've left one layer still operating w/ ConstantExpr because it makes the
interface quite a bit simpler, and that one isn't iterative so has much
lower cost.
I suppose this may potentially speed up some strang compilation
situations, but I don't really expect much. It should have no functional
impact either way.
llvm-svn: 152590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Typically instcombine has handled this, but pointer differences show up
in several contexts where we would like to get constant folding, and
cannot afford to run instcombine. Specifically, I'm working on improving
the constant folding of arguments used in inline cost analysis with
instsimplify.
Doing this in instsimplify implies some algorithm changes. We have to
handle multiple layers of all-constant GEPs because instsimplify cannot
fold them into a single GEP the way instcombine can. Also, we're only
interested in all-constant GEPs. The result is that this doesn't really
replace the instcombine logic, it's just complimentary and focused on
constant folding.
Reviewed on IRC by Benjamin Kramer.
llvm-svn: 152555
|
|
|
|
|
|
| |
format...for now.
llvm-svn: 152499
|
|
|
|
|
|
|
|
|
|
|
| |
The 'CmpInst::isFalseWhenEqual' function returns 'false' for values other than
simply equality. For instance, it returns 'false' for <= or >=. This isn't the
correct behavior for this transformation, which is checking for strict equality
and non-equality. It was causing the gcc.c-torture/execute/frame-address.c test
to fail because it would completely (and incorrectly) optimize a whole function
into a 'ret i32 0'.
llvm-svn: 152497
|
|
|
|
|
|
|
|
|
|
| |
a common collection of methods on Value, and share their implementation.
We had two variations in two different places already, and I need the
third variation for inline cost estimation.
Reviewed by Duncan Sands on IRC, but further comments here welcome.
llvm-svn: 152490
|
|
|
|
|
|
| |
'gep null' when the icmp predicate is unsigned (or is signed without inbounds).
llvm-svn: 151467
|
|
|
|
| |
llvm-svn: 151466
|
|
|
|
|
|
| |
MultiSource/Applications/lua.
llvm-svn: 151463
|
|
|
|
|
|
|
| |
equal if both are null. In the test, scope type %t and global @y by adding a
'gep' prefix to them.
llvm-svn: 151452
|
|
|
|
| |
llvm-svn: 151450
|
|
|
|
|
|
|
| |
by using llvm::isIdentifiedObject. Also teach it to handle GEPs that have
the same base pointer and constant operands. Fixes PR11238!
llvm-svn: 151449
|
|
|
|
|
|
| |
code, gep chains can be infinite. Just like "stripPointerCasts", use a set to keep track of visited instructions so we don't recurse infinitely.
llvm-svn: 151383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementing PR12013. We now compile the testcase to:
__Z4testv: ## @_Z4testv
## BB#0: ## %_ZN4llvm15SmallVectorImplIiE9push_backERKi.exit
pushq %rbx
subq $64, %rsp
leaq 32(%rsp), %rbx
movq %rbx, (%rsp)
leaq 64(%rsp), %rax
movq %rax, 16(%rsp)
movl $1, 32(%rsp)
leaq 36(%rsp), %rax
movq %rax, 8(%rsp)
leaq (%rsp), %rdi
callq __Z1gRN4llvm11SmallVectorIiLj8EEE
movq (%rsp), %rdi
cmpq %rbx, %rdi
je LBB0_2
## BB#1:
callq _free
LBB0_2: ## %_ZN4llvm11SmallVectorIiLj8EED1Ev.exit
addq $64, %rsp
popq %rbx
ret
instead of:
__Z4testv: ## @_Z4testv
## BB#0:
pushq %rbx
subq $64, %rsp
xorl %eax, %eax
leaq (%rsp), %rbx
addq $32, %rbx
movq %rbx, (%rsp)
movq %rbx, 8(%rsp)
leaq 64(%rsp), %rcx
movq %rcx, 16(%rsp)
je LBB0_2
## BB#1:
movl $1, 32(%rsp)
movq %rbx, %rax
LBB0_2: ## %_ZN4llvm15SmallVectorImplIiE9push_backERKi.exit
addq $4, %rax
movq %rax, 8(%rsp)
leaq (%rsp), %rdi
callq __Z1gRN4llvm11SmallVectorIiLj8EEE
movq (%rsp), %rdi
cmpq %rbx, %rdi
je LBB0_4
## BB#3:
callq _free
LBB0_4: ## %_ZN4llvm11SmallVectorIiLj8EED1Ev.exit
addq $64, %rsp
popq %rbx
ret
This doesn't shrink clang noticably though.
llvm-svn: 150944
|
|
|
|
|
|
| |
LHS->stripPointerCasts() != RHS->stripPointerCasts().
llvm-svn: 150863
|
|
|
|
|
|
|
| |
Turns out this isn't safe, because the code below depends on LHS and RHS having
the same type.
llvm-svn: 150695
|
|
|
|
| |
llvm-svn: 150694
|
|
|
|
|
|
| |
pointers.
llvm-svn: 150690
|
|
|
|
|
|
| |
don't assume it is a boolean.
llvm-svn: 150247
|
|
|
|
| |
llvm-svn: 149967
|
|
|
|
|
|
| |
it to simplify a few matchers.
llvm-svn: 147403
|
|
|
|
| |
llvm-svn: 145801
|
|
|
|
|
|
|
| |
InstructionSimplify.cpp. Other fixups as needed.
Part of rdar://10500969
llvm-svn: 145559
|
|
|
|
| |
llvm-svn: 145556
|
|
|
|
| |
llvm-svn: 144121
|
|
|
|
| |
llvm-svn: 143719
|
|
|
|
|
|
|
|
|
|
|
|
| |
with the given predicate, it matches any condition and returns the
predicate - d'oh! Original commit message:
The expression icmp eq (select (icmp eq x, 0), 1, x), 0 folds to false.
Spotted by my super-optimizer in 186.crafty and 450.soplex. We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.
llvm-svn: 143318
|
|
|
|
| |
llvm-svn: 143265
|
|
|
|
|
|
|
|
|
| |
Spotted by my super-optimizer in 186.crafty and 450.soplex. We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.
llvm-svn: 143214
|
|
|
|
|
|
| |
in 186.crafty.
llvm-svn: 143209
|
|
|
|
|
|
|
|
|
|
|
| |
using BinaryOperator (which only works for instructions) when it should have
been a cast to OverflowingBinaryOperator (which also works for constants).
While there, correct a few other dubious looking uses of BinaryOperator.
Thanks to Chad Rosier for the testcase. Original commit message:
My super-optimizer noticed that we weren't folding this expression to
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143125
|
|
|
|
|
|
| |
in 403.gcc and was spotted by my super-optimizer.
llvm-svn: 143054
|
|
|
|
|
|
|
|
| |
original value if types don't match.
Fixes clang selfhost.
llvm-svn: 139120
|
|
|
|
|
|
| |
up do-nothing exception handling code produced by dragonegg.
llvm-svn: 139113
|
|
|
|
|
|
| |
is clearly impossible given the current structure of the code.
llvm-svn: 137853
|
|
|
|
|
|
| |
how to actually trigger the codepath in question at the moment, but it might get exposed in the future.
llvm-svn: 137781
|
|
|
|
|
|
| |
reported at http://habrahabr.ru/blogs/compilers/125626/.
llvm-svn: 136865
|
|
|
|
|
|
|
| |
way for i1 and vector of i1 types. Use these to make some code
more self-documenting.
llvm-svn: 136079
|
|
|
|
| |
llvm-svn: 135904
|
|
|
|
|
|
| |
ConstantExpr::getInBoundsGetElementPtr to use ArrayRef.
llvm-svn: 135673
|
|
|
|
| |
llvm-svn: 135482
|
|
|
|
| |
llvm-svn: 135477
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 134223
|
|
|
|
|
|
|
| |
often expressed as "x >= y ? x : y", there is a good chance we can extract
the existing "x >= y" from it and use that as a replacement for "max(x,y)==x".
llvm-svn: 131049
|
|
|
|
|
|
| |
side of the icmp is an exact shift.
llvm-svn: 130954
|
|
|
|
|
|
|
|
| |
but according to my super-optimizer there are only two missed simplifications
of -instsimplify kind when compiling bzip2, and this is one of them. It amuses
me to have bzip2 be perfectly optimized as far as instsimplify goes!
llvm-svn: 130840
|
|
|
|
|
|
|
|
| |
max(a,b) >= a -> true. According to my super-optimizer, these are
by far the most common simplifications (of the -instsimplify kind)
that occur in the testsuite and aren't caught by -std-compile-opts.
llvm-svn: 130780
|
|
|
|
|
|
| |
a vector compare, generate a vector result rather than i1 (and crashing).
llvm-svn: 130706
|
|
|
|
|
|
|
| |
This automagically provides a transform noticed by my super-optimizer
as occurring quite often: "rem x, (select cond, x, 1)" -> 0.
llvm-svn: 130694
|
|
|
|
| |
llvm-svn: 129271
|