| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
with the Add code.
llvm-svn: 112430
|
|
|
|
| |
llvm-svn: 112429
|
|
|
|
| |
llvm-svn: 112428
|
|
|
|
| |
llvm-svn: 112337
|
|
|
|
|
|
| |
adjacent operands at once, instead of just two at a time.
llvm-svn: 112299
|
|
|
|
|
|
|
|
| |
transformation collect all the addrecs with the same loop
add combine them at once rather than starting everything over
at the first chance.
llvm-svn: 112290
|
|
|
|
|
|
| |
to DenseMap.
llvm-svn: 112281
|
|
|
|
|
|
|
| |
return to avoid needing two calls to test for equivalence, and sort
addrecs by their degree before examining their operands.
llvm-svn: 112267
|
|
|
|
|
|
|
|
|
| |
middle, copy the elements in two groups, rather than copying all the
elements and then doing an erase on the middle of the result. These
are SmallVectors, so we shouldn't expect to hit dynamic allocation
in the common case.
llvm-svn: 111151
|
|
|
|
| |
llvm-svn: 111147
|
|
|
|
| |
llvm-svn: 111145
|
|
|
|
| |
llvm-svn: 111144
|
|
|
|
| |
llvm-svn: 111143
|
|
|
|
| |
llvm-svn: 111142
|
|
|
|
|
|
| |
them to iterators.
llvm-svn: 111140
|
|
|
|
| |
llvm-svn: 111138
|
|
|
|
| |
llvm-svn: 111137
|
|
|
|
|
|
| |
for each add instruction. Ditto for Mul.
llvm-svn: 111136
|
|
|
|
| |
llvm-svn: 111135
|
|
|
|
|
|
|
| |
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
|