| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
essentially sorting the pair's arguments. I'd love to actually call sort
here, but I'm just not that crazy. ;]
llvm-svn: 152764
|
|
|
|
|
|
|
| |
This appears to not be the case with dragonegg at least in some
contexts. Hopefully will fix the bootstrap assert failure there.
llvm-svn: 152763
|
|
|
|
|
|
| |
side of things. This is all dead code.
llvm-svn: 152759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correlated pairs of pointer arguments at the callsite. This is designed
to recognize the common C++ idiom of begin/end pointer pairs when the
end pointer is a constant offset from the begin pointer. With the
C-based idiom of a pointer and size, the inline cost saw the constant
size calculation, and this provides the same level of information for
begin/end pairs.
In order to propagate this information we have to search for candidate
operations on a pair of pointer function arguments (or derived from
them) which would be simplified if the pointers had a known constant
offset. Then the callsite analysis looks for such pointer pairs in the
argument list, and applies the appropriate bonus.
This helps LLVM detect that half of bounds-checked STL algorithms
(such as hash_combine_range, and some hybrid sort implementations)
disappear when inlined with a constant size input. However, it's not
a complete fix due the inaccuracy of our cost metric for constants in
general. I'm looking into that next.
Benchmarks showed no significant code size change, and very minor
performance changes. However, specific code such as hashing is showing
significantly cleaner inlining decisions.
llvm-svn: 152752
|
|
|
|
|
|
|
|
| |
a worklist rather than a recursive call.
No functionality changed.
llvm-svn: 152706
|
|
|
|
|
|
|
| |
fixing rdar://11039258, an issue that came up when inspecting clang's
bootstrapped codegen.
llvm-svn: 152635
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default.
Added some notes relative to case iterators.
llvm-svn: 152532
|
|
|
|
| |
llvm-svn: 152515
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
it to analyze extractvalue(llvm.[us](add|sub).with.overflow.*) intrinsics!
llvm-svn: 152398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduced. Specifically, there are cost reductions for all
constant-operand icmp instructions against an alloca, regardless of
whether the alloca will in fact be elligible for SROA. That means we
don't want to abort the icmp reduction computation when we abort the
SROA reduction computation. That in turn frees us from the need to keep
a separate worklist and defer the ICmp calculations.
Use this new-found freedom and some judicious function boundaries to
factor the innards of computing the cost factor of any given instruction
out of the loop over the instructions and into static helper functions.
This greatly simplifies the code, and hopefully makes it more clear what
is happening here.
Reviewed by Eric Christopher. There is some concern that we'd like to
ensure this doesn't get out of hand, and I plan to benchmark the effects
of this change over the next few days along with some further fixes to
the inline cost.
llvm-svn: 152368
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136146.html
Implemented CaseIterator and it solves almost all described issues: we don't need to mix operand/case/successor indexing anymore. Base iterator class is implemented as a template since it may be initialized either from "const SwitchInst*" or from "SwitchInst*".
ConstCaseIt is just a read-only iterator.
CaseIt is read-write iterator; it allows to change case successor and case value.
Usage of iterator allows totally remove resolveXXXX methods. All indexing convertions done automatically inside the iterator's getters.
Main way of iterator usage looks like this:
SwitchInst *SI = ... // intialize it somehow
for (SwitchInst::CaseIt i = SI->caseBegin(), e = SI->caseEnd(); i != e; ++i) {
BasicBlock *BB = i.getCaseSuccessor();
ConstantInt *V = i.getCaseValue();
// Do something.
}
If you want to convert case number to TerminatorInst successor index, just use getSuccessorIndex iterator's method.
If you want initialize iterator from TerminatorInst successor index, use CaseIt::fromSuccessorIndex(...) method.
There are also related changes in llvm-clients: klee and clang.
llvm-svn: 152297
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
analysis to be methods on the cost analysis's function info object
instead of the code metrics object. These really are just users of the
code metrics, they're building the information for the function's
analysis.
This is the first step of growing the amount of information we collect
about a function in order to cope with pair-wise simplifications due to
allocas.
llvm-svn: 152283
|
|
|
|
|
|
| |
until after other inexpensive tests.
llvm-svn: 152195
|
|
|
|
| |
llvm-svn: 152070
|
|
|
|
| |
llvm-svn: 152066
|
|
|
|
|
|
|
|
|
|
| |
forming constant ranges.
This could probably be made a lot smarter, but this is a common case and doesn't require LVI to scan a lot
of code. With this change CVP can optimize away the "shift == 0" case in Hashing.h that only gets hit when
"shift" is in a range not containing 0.
llvm-svn: 151919
|
|
|
|
|
|
| |
defaults to the ABI alignment. Given that, make this code a bit more aggressive in such cases.
llvm-svn: 151584
|
|
|
|
|
|
| |
object given sufficient alignment. Fixes PR12098.
llvm-svn: 151553
|
|
|
|
|
|
|
| |
properties (invoke). Just assert that the instruction we return dominates
the insertion point.
llvm-svn: 151511
|
|
|
|
|
|
| |
build. Testcase is still reducing.
llvm-svn: 151474
|
|
|
|
| |
llvm-svn: 151472
|
|
|
|
| |
llvm-svn: 151471
|
|
|
|
|
|
|
|
| |
verifier does. This correctly handles invoke.
Thanks to Duncan, Andrew and Chris for the comments.
Thanks to Joerg for the early testing.
llvm-svn: 151469
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
| |
function that others can use, next to llvm::isIdentifiedObject.
llvm-svn: 151446
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 151238
|
|
|
|
| |
llvm-svn: 151169
|
|
|
|
| |
llvm-svn: 151127
|
|
|
|
|
|
|
|
| |
the dominance once the dominates method is fixed and why we can use the builder's
insertion point.
Fixes pr12048.
llvm-svn: 151125
|
|
|
|
| |
llvm-svn: 151079
|
|
|
|
| |
llvm-svn: 151026
|
|
|
|
| |
llvm-svn: 151025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
know where users will be added. Because of this, it cannot use
Builder.GetInsertPoint at all.
This patch
* removes the FIXME about adding the assert.
* adds a comment explaining hy we don't have one.
* removes a broken logic that only works for some callers and is not needed
since r150884.
* adds an assert to caller that would have caught the bug fixed by r150884.
llvm-svn: 151015
|
|
|
|
|
|
| |
derived from anything.
llvm-svn: 150975
|
|
|
|
|
|
| |
too.
llvm-svn: 150974
|