| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
when they are the same loop. Don't compare two instructions'
loop depths when they are in the same block.
llvm-svn: 111045
|
|
|
|
|
|
| |
rather than testing whether the loop contains the other's header.
llvm-svn: 111039
|
|
|
|
| |
llvm-svn: 111038
|
|
|
|
|
|
|
| |
the constant operand on the left, as that's where ScalarEvolution
will end up canonicalizing to.
llvm-svn: 111037
|
|
|
|
|
|
|
| |
associated loop. This avoids potentially expensive traversals
of the add recurrence's operands.
llvm-svn: 111034
|
|
|
|
|
|
|
|
| |
having it finish processing all of the muliply operands before
starting the whole getAddExpr process over again, instead of
immediately after the first simplification.
llvm-svn: 110916
|
|
|
|
| |
llvm-svn: 110915
|
|
|
|
|
|
|
|
| |
by having it finish processing the whole operand list before
starting the whole getAddExpr process over again, instead of
immediately after the first duplicate is found.
llvm-svn: 110914
|
|
|
|
|
|
|
| |
make any assumptions about when the two conditions will agree on when
to permit the loop to exit. This fixes PR7845.
llvm-svn: 110758
|
|
|
|
| |
llvm-svn: 110750
|
|
|
|
| |
llvm-svn: 110460
|
|
|
|
| |
llvm-svn: 110410
|
|
|
|
|
|
|
|
| |
address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
|
|
|
|
|
| |
using wider types than are necessary.
llvm-svn: 110241
|
|
|
|
|
|
|
|
|
|
|
| |
of Value deletions and RAUWs, instead of relying on ScalarEvolution's
Scalars map being notified, as that's complicated at best, and
insufficient in general.
This means SCEVUnknown needs a non-trivial destructor, so introduce
a mechanism to allow ScalarEvolution to locate all the SCEVUnknowns.
llvm-svn: 110086
|
|
|
|
|
|
|
|
| |
Fixes potential ambiguity problems on VS 2010.
Patch by nobled!
llvm-svn: 110029
|
|
|
|
|
|
| |
angst.
llvm-svn: 109718
|
|
|
|
|
|
|
|
|
| |
extend it to handle the case where multiple RAUWs affect a single
SCEVUnknown.
Add a ScalarEvolution unittest to test for this situation.
llvm-svn: 109705
|
|
|
|
|
|
|
|
|
|
|
|
| |
object, as it may still be referenced by SCEVs not cleaned up by the
use list traversal.
Also, in ScalarEvolution::forgetValue, only check for a SCEVUnknown
object for the original value, not for any value in the use list,
because other SCEVUnknown values aren't necessary obsolete at that
point.
llvm-svn: 109570
|
|
|
|
|
|
| |
the old value.
llvm-svn: 109567
|
|
|
|
| |
llvm-svn: 109267
|
|
|
|
| |
llvm-svn: 109266
|
|
|
|
| |
llvm-svn: 109103
|
|
|
|
| |
llvm-svn: 109045
|
|
|
|
| |
llvm-svn: 108855
|
|
|
|
|
|
| |
This helps LSR behave more consistently on bugpoint-reduced testcases.
llvm-svn: 108451
|
|
|
|
|
|
|
|
|
|
|
| |
entries associated with the value being erased in the
folding set map. These entries used to be harmless, because
a SCEVUnknown doesn't store any information about its Value*,
so having a new Value allocated at the old Value's address
wasn't a problem. But now that ScalarEvolution is storing more
information about values, this is no longer safe.
llvm-svn: 107316
|
|
|
|
|
|
|
| |
nsw and nuw flags from IR Instructions. On further consideration,
this isn't valid.
llvm-svn: 107298
|
|
|
|
| |
llvm-svn: 107257
|
|
|
|
|
|
| |
the old one instead of replacing it, to be more precise.
llvm-svn: 107256
|
|
|
|
|
|
|
| |
where each loop's induction variable's start value is the exit
value of a preceding loop.
llvm-svn: 107224
|
|
|
|
|
|
|
|
| |
instruction to an add scev, it's not safe to blindly transfer the
inbounds flag from a gep instruction to an nsw on the scev for the
gep.
llvm-svn: 107117
|
|
|
|
| |
llvm-svn: 106872
|
|
|
|
|
|
| |
was over-complicated.
llvm-svn: 106760
|
|
|
|
|
|
| |
handling of pointer types.
llvm-svn: 106757
|
|
|
|
|
|
| |
with LoopInfo's public copy.
llvm-svn: 106603
|
|
|
|
|
|
| |
constant operands.
llvm-svn: 106537
|
|
|
|
|
|
| |
SmallVector, and other SmallVector simplifications.
llvm-svn: 106452
|
|
|
|
|
|
|
|
| |
assuming that loops are in canonical form, as ScalarEvolution doesn't
depend on LoopSimplify itself. Also, with indirectbr not all loops can
be simplified. This fixes PR7416.
llvm-svn: 106389
|
|
|
|
|
|
| |
optimizations. There is still some nondeterminism remaining.
llvm-svn: 106306
|
|
|
|
| |
llvm-svn: 106304
|
|
|
|
| |
llvm-svn: 106302
|
|
|
|
| |
llvm-svn: 106301
|
|
|
|
|
|
| |
is more consistent with the ConstantInt API.
llvm-svn: 106281
|
|
|
|
| |
llvm-svn: 106254
|
|
|
|
| |
llvm-svn: 105740
|
|
|
|
|
|
|
| |
determinstic. Instead, give SCEV objects an arbitrary sequence
number.
llvm-svn: 105548
|
|
|
|
|
|
| |
that the operands are sorted.
llvm-svn: 105546
|
|
|
|
| |
llvm-svn: 105544
|
|
|
|
| |
llvm-svn: 105542
|