[llvm-dev] [LSR] Post-inc load/store cost model in loop strength reduction
Lei Liu via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 20 18:36:57 PST 2018
Hi,
I found LSR does not accurately model an IV increment cost on my target
with post-inc load/store instructions for particular types. The related code
is in lib/Transforms/Scalar/LoopStrengthReduce.cpp:
void Cost::RateRegister()
...
unsigned LoopCost = 1;
if (TTI.shouldFavorPostInc()) {
const SCEV *LoopStep = AR->getStepRecurrence(SE);
if (isa<SCEVConstant>(LoopStep)) {
// Check if a post-indexed load/store can be used.
if (TTI.isIndexedLoadLegal(TTI.MIM_PostInc, AR->getType()) ||
TTI.isIndexedStoreLegal(TTI.MIM_PostInc, AR->getType())) {
const SCEV *LoopStart = AR->getStart();
if (!isa<SCEVConstant>(LoopStart) &&
SE.isLoopInvariant(LoopStart, L))
LoopCost = 0;
}
}
Here we consult TTI with TTI.isIndexLoadLegal() to see if post-inc load/store
is supported on the target, in which case the IV increment could be folded
into the load/store to save one instruction.
However this code does not make sense to me.
1) We don’t know if the use of this IV is a load/store.
2) Should we pass the type of the load/store instead of the type of IV
to isIndexedLoadLocal()?
3) I don’t understand why LoopStart needs to be a loop invariant but not a
Constant for the post-inc fold to be valid. I think the constant loop start case
is also benefit from the post-inc load/store.
Thanks,
Lei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181221/b751b09d/attachment.html>
More information about the llvm-dev
mailing list