llvm-svn: 72130

instructions. It attempts to create high-level multi-operand GEPs,
though in cases where this isn't possible it falls back to casting
the pointer to i8* and emitting a GEP with that. Using GEP instructions
instead of ptrtoint+arithmetic+inttoptr helps pointer analyses that
don't use ScalarEvolution, such as BasicAliasAnalysis.

Also, make the AddrModeMatcher more aggressive in handling GEPs.
Previously it assumed that operand 0 of a GEP would require a register
in almost all cases. It now does extra checking and can do more
matching if operand 0 of the GEP is foldable. This fixes a problem
that was exposed by SCEVExpander using GEPs.

llvm-svn: 72093

avoid ambiguity with the word "use" in IVStrideUse.

llvm-svn: 72012

without one.  Use it where we were using abs on
int64_t objects.
(I strongly suspect the casts to unsigned in the
fragments in LoopStrengthReduce are not doing whatever
the original intent was, but the obvious change to
uint64_t doesn't work.  Maybe later.)

llvm-svn: 71612

and generalize it so that it can be used by IndVarSimplify. Implement the
base IndVarSimplify transformation code using IVUsers. This removes
TestOrigIVForWrap and associated code, as ScalarEvolution now has enough
builtin overflow detection and folding logic to handle all the same cases,
and more. Run "opt -iv-users -analyze -disable-output" on your favorite
loop for an example of what IVUsers does.

This lets IndVarSimplify eliminate IV casts and compute trip counts in
more cases. Also, this happens to finally fix the remaining testcases
in PR1301.

Now that IndVarSimplify is being more aggressive, it occasionally runs
into the problem where ScalarEvolutionExpander's code for avoiding
duplicate expansions makes it difficult to ensure that all expanded
instructions dominate all the instructions that will use them. As a
temporary measure, IndVarSimplify now uses a FixUsesBeforeDefs function
to fix up instructions inserted by SCEVExpander. Fortunately, this code
is contained, and can be easily removed once a more comprehensive
solution is available.

llvm-svn: 71535

Teach LSR to optimize more loop exit compares, i.e. change them to use postinc iv value. Previously LSR would only optimize those which are in the loop latch block. However, if LSR can prove it is safe (and profitable), it's now possible to change those not in the latch blocks to use postinc values.

Also, if the compare is the only use, LSR would place the iv increment instruction before the compare instead in the latch.

llvm-svn: 71485

count down to 0 instead, under very restricted
circumstances.  Adjust 4 testcases in which this
optimization fires.

llvm-svn: 71439

llvm-svn: 71305

llvm-svn: 71091

Make sure to use signed arithmetic in APInt to fix a regression.

llvm-svn: 71090

llvm-svn: 71035

llvm-svn: 71033

Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/test/
CodeGen/X86/dg.exp ...
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/test/
CodeGen/X86/change-compare-stride-1.ll
Failed with exit(1) at line 2
while running: grep {cmpq       $-478,} change-compare-stride-1.ll.tmp
child process exited abnormally

llvm-svn: 71013

Handle overflow of 64-bit loop conditions.

llvm-svn: 71008

CallbackVH, with fixes. allUsesReplacedWith need to
walk the def-use chains and invalidate all users of a
value that is replaced. SCEVs of users need to be
recalcualted even if the new value is equivalent. Also,
make forgetLoopPHIs walk def-use chains, since any
SCEV that depends on a PHI should be recalculated when
more information about that PHI becomes available.

llvm-svn: 70927

llvm-svn: 70919

llvm-svn: 70661

makes ScalarEvolution::deleteValueFromRecords, and it's code that
subtly needed to be called before ReplaceAllUsesWith, unnecessary.

It also makes ValueDeletionListener unnecessary.

llvm-svn: 70645

of returning a list of pointers to Values that are deleted. This was
unsafe, because the pointers in the list are, by nature of what
RecursivelyDeleteDeadInstructions does, always dangling. Replace this
with a simple callback mechanism. This may eventually be removed if
all clients can reasonably be expected to use CallbackVH.

Use this to factor out the dead-phi-cycle-elimination code from LSR
utility function, and generalize it to use the
RecursivelyDeleteTriviallyDeadInstructions utility function.

This makes LSR more aggressive about eliminating dead PHI cycles;
adjust tests to either be less trivial or to simply expect fewer
instructions.

llvm-svn: 70636

of LSR. This makes the AddUsersIfInteresting phase of LSR a pure
analysis instead of a phase that potentially does CFG modifications.

The conditions where this code would actually perform a split are
rare, and in the cases where it actually would do a split the split
is usually undone by CodeGenPrepare, and in cases where splits
actually survive into codegen, they appear to hurt more often than
they help.

llvm-svn: 70625

target hooks canLosslesslyBitCastTo and isTruncateFree. This allows
targets to avoid worrying about handling all combinations of integer
and pointer types.

llvm-svn: 70555

llvm-svn: 70551

llvm-svn: 70546

llvm-svn: 70427

between the comparison's iv stride and the candidate stride is
exactly -1.

llvm-svn: 70244

and SCEVSignExtendExpr.

llvm-svn: 69649

the code to minimize dependencies on TargetData.

llvm-svn: 69644

llvm-svn: 69450

regression in 403.gcc in PIC_CODEGEN=1 and DISABLE_LTO=1
mode.

llvm-svn: 69344

to get the correct answer for pointer types.

llvm-svn: 69321

targets with pointers larger than 64 bits, due to the code not
yet being APInt clean.

llvm-svn: 69296

optimizer, which just happen to frequently involve optimizing GEPs.

llvm-svn: 69295

since the operand is always a constant.

llvm-svn: 69291

new instruction with SCEVExpander::InsertCastOfTo.

llvm-svn: 69290

have pointer types, though in contrast to C pointer types, SCEV
addition is never implicitly scaled. This not only eliminates the
need for special code like IndVars' EliminatePointerRecurrence
and LSR's own GEP expansion code, it also does a better job because
it lets the normal optimizations handle pointer expressions just
like integer expressions.

Also, since LLVM IR GEPs can't directly index into multi-dimensional
VLAs, moving the GEP analysis out of client code and into the SCEV
framework makes it easier for clients to handle multi-dimensional
VLAs the same way as other arrays.

Some existing regression tests show improved optimization.
test/CodeGen/ARM/2007-03-13-InstrSched.ll in particular improved to
the point where if-conversion started kicking in; I turned it off
for this test to preserve the intent of the test.

llvm-svn: 69258

it is not APInt clean, but even when it is it needs to be evaluated carefully
to determine whether it is actually profitable.

This fixes a crash on PR3806

llvm-svn: 67134

if needed. This simplifies the code a little, and is needed for an
upcoming refactoring.

llvm-svn: 66479

where memory access types are needed.

llvm-svn: 66470

llvm-svn: 66469

llvm-svn: 66467