| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
worklist. This can happen in theory when an instruction uses itself,
such as a PHI node. This was spotted by inspection, and unfortunately
I've not been able to come up with a test case that would trigger it. If
anyone has ideas, let me know...
llvm-svn: 153396
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bit simpler by handling a common case explicitly.
Also, refactor the implementation to use a worklist based walk of the
recursive users, rather than trying to use value handles to detect and
recover from RAUWs during the recursive descent. This fixes a very
subtle bug in the previous implementation where degenerate control flow
structures could cause mutually recursive instructions (PHI nodes) to
collapse in just such a way that From became equal to To after some
amount of recursion. At that point, we hit the inf-loop that the assert
at the top attempted to guard against. This problem is defined away when
not using value handles in this manner. There are lots of comments
claiming that the WeakVH will protect against just this sort of error,
but they're not accurate about the actual implementation of WeakVHs,
which do still track RAUWs.
I don't have any test case for the bug this fixes because it requires
running the recursive simplification on unreachable phi nodes. I've no
way to either run this or easily write an input that triggers it. It was
found when using instruction simplification inside the inliner when
running over the nightly test-suite.
llvm-svn: 153393
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not attched to a basic block or function. There are conservatively
correct answers in these cases, and this makes the analysis more useful
in contexts where we have a partially formed bit of IR.
I don't have any way to test this directly... suggestions welcome here,
but I'm not seeing anything sadly. I only found this using a subsequent
patch to the inliner which runs instsimplify on partially inlined
instructions, and even then only on a quite large program. I never got
a reasonable testcase out of it, and anything I do get is likely to be
quite fragile due to requiring an interaction of two different passes,
and the only result being a segfault if it goes wrong.
llvm-svn: 153176
|
|
|
|
|
|
|
| |
theoretical fix since it only matters for types with >= 2^63 bits (!) and also
only matters if pointers have more than 64 bits, which is not supported anyway.
llvm-svn: 152831
|
|
|
|
|
|
| |
trunc(ptrtoint(x-y))" optimization introduced by Chandler.
llvm-svn: 152626
|
|
|
|
|
|
|
|
| |
take a TargetLibraryInfo parameter. Internally, rather than passing TD, TLI
and DT parameters around all over the place, introduce a struct for holding
them.
llvm-svn: 152623
|
|
|
|
|
|
| |
reachable from the entry block with uses of an instruction not reachable from the entry block. PR12231.
llvm-svn: 152595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|