| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 122977
|
| |
|
|
|
|
|
|
|
|
| |
ret i64 ptrtoint (i8* getelementptr ([1000 x i8]* @X, i64 1, i64 sub (i64 0, i64 ptrtoint ([1000 x i8]* @X to i64))) to i64)
to "ret i64 1000". This allows us to correctly compute the trip count
on a loop in PR8883, which occurs with std::fill on a char array. This
allows us to transform it into a memset with a constant size.
llvm-svn: 122950
|
| |
|
|
| |
llvm-svn: 122929
|
| |
|
|
|
|
|
|
| |
compute the value range
in the predecessor block, leading to an incorrect conclusion for the edge value. Found by inspection.
llvm-svn: 122908
|
| |
|
|
|
|
|
|
|
| |
fix the issue in
hasBlockValue() that was causing iterator invalidations. Many thanks to Dimitry Andric for
tracking down those invalidations!
llvm-svn: 122906
|
| |
|
|
|
|
| |
ashr's with huge shift amounts, PR8896
llvm-svn: 122814
|
| |
|
|
|
|
|
|
| |
PHIs of GEPs. For the moment,
have GlobalsModRef handle this conservatively by simply removing the value from its maps.
llvm-svn: 122787
|
| |
|
|
|
|
|
|
|
| |
analyses to be informed when
a pointer value has potentially become escaping. Implementations can choose to either fall back to
conservative responses for that value, or may recompute their analysis to accomodate the change.
llvm-svn: 122777
|
| |
|
|
|
|
| |
exposed. It turns out to be a latent bug in basicaa, scary.
llvm-svn: 122772
|
| |
|
|
|
|
|
|
|
|
| |
update a callGraph when performing the common operation of splicing the body to
a new function and updating all callers (such as via RAUW).
No users yet, though this is intended for DeadArgumentElimination as part of
PR8887.
llvm-svn: 122728
|
| |
|
|
|
|
| |
so that Dominators.h is *just* domtree. Also prune #includes a bit.
llvm-svn: 122714
|
| |
|
|
|
|
| |
is the wrong hammer for this nail, and is probably right.
llvm-svn: 122661
|
| |
|
|
|
|
|
|
|
|
|
| |
numbering, in which it considers (for example) "%a = add i32 %x, %y" and
"%b = add i32 %x, %y" to be equal because the operands are equal and the
result of the instructions only depends on the values of the operands.
This has almost no effect (it removes 4 instructions from gcc-as-one-file),
and perhaps slows down compilation: I measured a 0.4% slowdown on the large
gcc-as-one-file testcase, but it wasn't statistically significant.
llvm-svn: 122654
|
| |
|
|
| |
llvm-svn: 122598
|
| |
|
|
| |
llvm-svn: 122565
|
| |
|
|
|
|
|
| |
new gcc warning that complains on self-assignments and
self-initializations.
llvm-svn: 122458
|
| |
|
|
|
|
|
|
| |
the original instruction, half the cases were missed (making it not
wrong but suboptimal). Also correct a typo (A <-> B) in the second
chunk.
llvm-svn: 122414
|
| |
|
|
|
|
| |
instcombine is compared to instsimplify.
llvm-svn: 122397
|
| |
|
|
|
|
|
| |
not assume this (for example in case more transforms get added below
it). Suggested by Frits van Bommel.
llvm-svn: 122332
|
| |
|
|
| |
llvm-svn: 122331
|
| |
|
|
|
|
| |
plenty left though!), in particular for multiplication.
llvm-svn: 122330
|
| |
|
|
|
|
|
| |
quite often, but don't make much difference in practice presumably because
instcombine also knows them and more.
llvm-svn: 122328
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 122327
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a couple of existing transforms. This fires surprisingly often, for
example when compiling gcc "(X+(-1))+1->X" fires quite a lot as well
as various "and" simplifications (usually with a phi node operand).
Most of the time this doesn't make a real difference since the same
thing would have been done elsewhere anyway, eg: by instcombine, but
there are a few places where this results in simplifications that we
were not doing before.
llvm-svn: 122326
|
| |
|
|
|
|
| |
causing Linux self-host failures.
llvm-svn: 122291
|
| |
|
|
| |
llvm-svn: 122288
|
| |
|
|
|
|
| |
assured of iterator stability.
llvm-svn: 122273
|
| |
|
|
|
|
| |
the OverDefinedCache.
llvm-svn: 122256
|
| |
|
|
|
|
|
|
| |
This is much easier to
verify as being safe thanks its recent de-recursivization.
llvm-svn: 122254
|
| |
|
|
|
|
|
| |
(they had just been forgotten before). Adding Xor causes "main" in the
existing testcase 2010-11-01-lshr-mask.ll to be hugely more simplified.
llvm-svn: 122245
|
| |
|
|
| |
llvm-svn: 122120
|
| |
|
|
|
|
| |
matching psign & pblend operations to the IR produced by clang/gcc for their C idioms.
llvm-svn: 122105
|
| |
|
|
| |
llvm-svn: 121946
|
| |
|
|
| |
llvm-svn: 121944
|
| |
|
|
| |
llvm-svn: 121923
|
| |
|
|
|
|
| |
it in sync.
llvm-svn: 121895
|
| |
|
|
|
|
| |
in sync.
llvm-svn: 121892
|
| |
|
|
|
|
|
|
|
|
| |
While LLVM's main design is that analysis code shouldn't
go out of its way to understand code which hasn't been
InstCombined, analysis utility routines like this can
find themselves being called in the middle of transform
passes when instcombine hasn't had a chance to run.
llvm-svn: 121886
|
| |
|
|
|
|
|
| |
function so that it can live in Analysis instead of
VMCore.
llvm-svn: 121885
|
| |
|
|
|
|
|
|
| |
* mergeIn now uses constant folding for constants that are provably not-equal.
* sink some sanity checks from the get*() methods into the mark*() methods, to ensure that we never have a constant/notconstant ConstantInt
* some textual cleanups, whitespace changes, removing "else" after return, that sort of thing.
llvm-svn: 121877
|
| |
|
|
|
|
| |
instcombine and into InstructionSimplify.
llvm-svn: 121861
|
| |
|
|
|
|
|
| |
it to be replaced by undef rather than not replaced at all, the idea being that
this may reduce the amount of work done by whoever called InstructionSimplify.
llvm-svn: 121860
|
| |
|
|
| |
llvm-svn: 121727
|
| |
|
|
|
|
| |
memdep is updated to handle it.
llvm-svn: 121725
|
| |
|
|
| |
llvm-svn: 121723
|
| |
|
|
|
|
|
| |
Thanks Peter for pointing me to something that should have never been
committed to the llvm code base.
llvm-svn: 121648
|
| |
|
|
| |
llvm-svn: 121573
|
| |
|
|
| |
llvm-svn: 121520
|
| |
|
|
| |
llvm-svn: 121518
|
| |
|
|
| |
llvm-svn: 121514
|