llvm dev - Dec 2018 - [LSR] Post-inc load/store cost model in loop strength reduction

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>