| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
different widths. In a use with a narrower fixup, formulae
may be wider than the fixup, in which case the high bits
aren't necessarily meaningful, so it isn't safe to reuse
them for uses with wider fixups.
This fixes PR7618, though the testcase is too large for a
reasonable regression test, since it heavily dependes on
hitting LSR's heuristics in a certain way.
llvm-svn: 108455
|
|
|
|
| |
llvm-svn: 108453
|
|
|
|
|
|
|
| |
a zero. This situation arrises in Fortran code with induction variables
that start at 1 instead of 0. This fixes PR7651.
llvm-svn: 108424
|
|
|
|
| |
llvm-svn: 107270
|
|
|
|
|
|
|
|
| |
SCEVUnknown values which are loop-variant, as LSR can't do anything
interesting with these values in any case. This fixes very slow compile
times on loops which have large numbers of such values.
llvm-svn: 106897
|
|
|
|
| |
llvm-svn: 106764
|
|
|
|
|
|
|
| |
enough special case, and it theoretically allows more folding because
it works even when x is unanalyzable.
llvm-svn: 106763
|
|
|
|
| |
llvm-svn: 106759
|
|
|
|
|
|
| |
is another max which folds. This fixes PR7454.
llvm-svn: 106594
|
|
|
|
|
|
| |
SmallVector, and other SmallVector simplifications.
llvm-svn: 106452
|
|
|
|
| |
llvm-svn: 106397
|
|
|
|
|
|
|
|
|
|
|
|
| |
use sharing map. The reconcileNewOffset logic already forces a
separate use if the kinds differ, so incorporating the kind in the
key means we can track more sharing opportunities.
More sharing means fewer total uses to track, which means smaller
problem sizes, which means the conservative throttles don't kick
in as often.
llvm-svn: 106396
|
|
|
|
| |
llvm-svn: 106395
|
|
|
|
|
|
| |
register pressure.
llvm-svn: 105501
|
|
|
|
| |
llvm-svn: 104290
|
|
|
|
| |
llvm-svn: 104287
|
|
|
|
|
|
| |
top-level LSRInstance logic.
llvm-svn: 104278
|
|
|
|
| |
llvm-svn: 104276
|
|
|
|
|
|
| |
aren't needed.
llvm-svn: 104273
|
|
|
|
|
|
|
|
|
| |
Changed directly instead of using a return value.
Rename FilterOutUndesirableDedicatedRegisters's Changed variable to
distinguish it from LSRInstance's Changed member.
llvm-svn: 104269
|
|
|
|
| |
llvm-svn: 104268
|
|
|
|
| |
llvm-svn: 104267
|
|
|
|
| |
llvm-svn: 104263
|
|
|
|
|
|
|
|
|
|
|
|
| |
operand on the left, the interesting operand is on the right. This
fixes a bug where LSR was failing to recognize ICmpZero uses,
which led it to be unable to reverse the induction variable in the
attached testcase.
Delete test/CodeGen/X86/stack-color-with-reg-2.ll, because its test
is extremely fragile and hard to meaningfully update.
llvm-svn: 104262
|
|
|
|
|
|
| |
it isn't a very interesting change, it's a change nonetheless.
llvm-svn: 104260
|
|
|
|
| |
llvm-svn: 104234
|
|
|
|
| |
llvm-svn: 104232
|
|
|
|
|
|
|
| |
and fix a bug that valgrind noticed where the code would std::swap an
element with itself.
llvm-svn: 104225
|
|
|
|
|
|
|
|
| |
the addressing modes don't make this trivially easy. This allows
it to avoid falling into the less precise heuristics in more
cases.
llvm-svn: 104186
|
|
|
|
| |
llvm-svn: 104089
|
|
|
|
|
|
| |
constants in registers which partially cancel out their immediate fields.
llvm-svn: 104088
|
|
|
|
|
|
|
| |
of its formulae have been removed into a helper function, and also
teach it how to update the RegUseTracker.
llvm-svn: 104087
|
|
|
|
|
|
| |
function.
llvm-svn: 104082
|
|
|
|
| |
llvm-svn: 104080
|
|
|
|
|
|
| |
a helper function.
llvm-svn: 104079
|
|
|
|
| |
llvm-svn: 104078
|
|
|
|
|
|
|
| |
is inconsistent with the BaseRegs field. It's not print's job to
assert on an invalid condition, but it can make one more obvious.
llvm-svn: 104077
|
|
|
|
|
|
| |
confusion with LSRInstance's RegUses member.
llvm-svn: 104076
|
|
|
|
| |
llvm-svn: 103457
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.
This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.
Also, add a few asserts to diagnose this kind of situation.
llvm-svn: 103328
|
|
|
|
|
|
| |
same, now that getConstant has overloads consistent with ConstantInt::get.
llvm-svn: 102965
|
|
|
|
|
|
| |
that indvars may use, now that indvars is recognizing le and ge loops.
llvm-svn: 102235
|
|
|
|
|
|
|
| |
misses an opportunity to fold add operands, but folds them
after LSR has separated them out. This fixes rdar://7886751.
llvm-svn: 102157
|
|
|
|
|
|
|
| |
just ask ScalarEvolution for it on demand. This helps IVUsers be more robust
in the case of expressions changing underneath it. This fixes PR6862.
llvm-svn: 101819
|
|
|
|
| |
llvm-svn: 101033
|
|
|
|
|
|
|
|
| |
into adjacent loops. Also, ensure that the insert position is
dominated by the loop latch of any loop in the post-inc set which
has a latch.
llvm-svn: 100906
|
|
|
|
|
|
|
| |
so that an unfortunately placed bitcast doesn't pin a value in a
register.
llvm-svn: 100883
|
|
|
|
|
|
| |
a separate function.
llvm-svn: 100845
|
|
|
|
|
|
| |
inputs happen to negate each other.
llvm-svn: 100828
|
|
|
|
| |
llvm-svn: 100824
|