| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 139139
|
|
|
|
| |
llvm-svn: 139138
|
|
|
|
| |
llvm-svn: 139137
|
|
|
|
|
|
| |
add more showing of my work.
llvm-svn: 139136
|
|
|
|
| |
llvm-svn: 139135
|
|
|
|
| |
llvm-svn: 139134
|
|
|
|
|
|
|
| |
visible given a=b=c=d=1, on iteration #1 (the second iteration). Replace it with
correct math. Fixes PR10383!
llvm-svn: 139133
|
|
|
|
| |
llvm-svn: 139130
|
|
|
|
|
|
| |
HowFarToZero; the case for a canonical loop.
llvm-svn: 139126
|
|
|
|
| |
llvm-svn: 139036
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SCEV unrolling can unroll loops with arbitrary induction variables. It
is a prerequisite for -disable-iv-rewrite performance. It is also
easily handles loops of arbitrary structure including multiple exits
and is generally more robust.
This is under a temporary option to avoid affecting default
behavior for the next couple of weeks. It is needed so that I can
checkin unit tests for updateUnloop.
llvm-svn: 137384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
recurrence, the initial values low bits can sometimes be ignored.
To take advantage of this, added FoldIVUser to IndVarSimplify to fold
an IV operand into a udiv/lshr if the operator doesn't affect the
result.
-indvars -disable-iv-rewrite now transforms
i = phi i4
i1 = i0 + 1
idx = i1 >> (2 or more)
i4 = i + 4
into
i = phi i4
idx = i0 >> ...
i4 = i + 4
llvm-svn: 137013
|
|
|
|
| |
llvm-svn: 136677
|
|
|
|
|
|
|
| |
exit. Added an interfaces for querying either the loop's exact/max
backedge taken count or a specific loop exit's not-taken count.
llvm-svn: 136100
|
|
|
|
| |
llvm-svn: 135477
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 132416
|
|
|
|
|
|
| |
so that their sign extended forms are congruent when no overflow occurs.
llvm-svn: 132360
|
|
|
|
| |
llvm-svn: 131088
|
|
|
|
| |
llvm-svn: 130316
|
|
|
|
| |
llvm-svn: 130294
|
|
|
|
|
|
|
|
|
| |
incompatible type!"' failed.
Added a type check in ScalarEvolution::computeSCEVAtScope to handle the case in which operands of an
AddRecExpr in the current scope are folded.
llvm-svn: 130271
|
|
|
|
| |
llvm-svn: 130166
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
|
|
|
|
|
|
|
|
| |
SCEV may generate expressions composed of multiple pointers, which can
lead to invalid GEP expansion. Until we can teach SCEV to follow strict
pointer rules, make sure no bad GEPs creep into IR.
Fixes rdar://problem/9038671.
llvm-svn: 127839
|
|
|
|
|
|
|
| |
This function performed acrobatics to prove no-self-wrap, which we now
have for free.
llvm-svn: 127643
|
|
|
|
|
|
| |
This needs review.
llvm-svn: 127638
|
|
|
|
| |
llvm-svn: 127593
|
|
|
|
|
|
| |
no-self-wrap.
llvm-svn: 127591
|
|
|
|
|
|
|
|
|
| |
properties.
Added the self-wrap flag for SCEV::AddRecExpr.
A slew of temporary FIXMEs indicate the intention of the no-self-wrap flag
without changing behavior in this revision.
llvm-svn: 127590
|
|
|
|
|
|
|
|
| |
When ExactBECount is a constant, use it for MaxBECount.
When MaxBECount cannot be computed, replace it with ExactBECount.
Fixes PR9424.
llvm-svn: 127342
|
|
|
|
| |
llvm-svn: 127340
|
|
|
|
|
|
|
| |
This fixes a FIXME in scev-aa.ll (allowing a new no-alias result) and
generally makes things more precise.
llvm-svn: 125449
|
|
|
|
|
|
|
|
|
|
|
| |
unsigned overflow (e.g. "gep P, -1"), and while they can have
signed wrap in theoretical situations, modelling an AddRec as
not having signed wrap is going enough for any case we can
think of today. In the future if this isn't enough, we can
revisit this. Modeling them as having NUW isn't causing any
known problems either FWIW.
llvm-svn: 125410
|
|
|
|
|
|
|
| |
doesn't return immediately after then the insert position in UniqueSCEVs will
be out of date. No test because this is a memory corruption issue. Fixes PR9051!
llvm-svn: 124282
|
|
|
|
| |
llvm-svn: 124126
|
|
|
|
|
|
| |
robust against smarter optimizations, using the power of FileCheck.
llvm-svn: 124081
|
|
|
|
| |
llvm-svn: 124062
|
|
|
|
|
|
| |
"make check" alone.
llvm-svn: 124046
|
|
|
|
| |
llvm-svn: 123842
|
|
|
|
|
|
|
|
|
|
|
| |
by indvars through the scev expander.
trunc(add x, y) --> add(trunc x, y). Currently SCEV largely folds the other way
which is probably wrong, but preserved to minimize churn. Instcombine doesn't
do this fold either, demonstrating a missed optz'n opportunity on code doing
add+trunc+add.
llvm-svn: 123838
|
|
|
|
| |
llvm-svn: 123832
|
|
|
|
| |
llvm-svn: 123243
|
|
|
|
|
|
| |
to get a testcase.
llvm-svn: 123225
|
|
|
|
| |
llvm-svn: 123218
|
|
|
|
| |
llvm-svn: 123139
|
|
|
|
|
|
|
| |
NUW AddRec's much more aggressively. We now get a trip count
for @test2 in nsw.ll
llvm-svn: 123138
|
|
|
|
| |
llvm-svn: 123136
|
|
|
|
|
|
|
|
| |
a + {b,+,stride} into {a+b,+,stride} (because a is LIV),
then the resultant AddRec is NUW/NSW if the client says it
is.
llvm-svn: 123133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
void f(int* begin, int* end) { std::fill(begin, end, 0); }
which turns into a != exit expression where one pointer is
strided and (thanks to step #1) known to not overflow, and
the other is loop invariant.
The observation here is that, though the IV is strided by
4 in this case, that the IV *has* to become equal to the
end value. It cannot "miss" the end value by stepping over
it, because if it did, the strided IV expression would
eventually wrap around.
Handle this by turning A != B into "A-B != 0" where the A-B
part is known to be NUW.
llvm-svn: 123131
|