[LLVMdev] Suggestion About Adding Target Dependent Decision in LSR Please

Yin Ma yinma at codeaurora.org
Wed Mar 13 16:37:11 PDT 2013

Hi All,


In the target I am working, we comes cross a situation that the loop
strength reduction

could deliver a better result but currently not, because 

1.       the algorithm narrows search space by winner registers without

the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs)

2.       Cost comparison solely favors the number register without
considering other



For the case one,

NarrowSearchSpaceByPickingWinnerRegs filters by most occurred registers.

ld(basereg, immediate) is a target preferred addressing mode. However, it

be deleted because basereg is very likely not to be the most occurred

because the less opportunity in a combination. 


For the case two, by observing the cost comparison equation

bool Cost::operator<(const Cost &Other) const {

  if (NumRegs != Other.NumRegs)                            return NumRegs <

  if (AddRecCost != Other.AddRecCost)                  return AddRecCost <

  if (NumIVMuls != Other.NumIVMuls)                   return NumIVMuls <

  if (NumBaseAdds != Other.NumBaseAdds)       return NumBaseAdds <

  if (ImmCost != Other.ImmCost)                               return ImmCost
< Other.ImmCost;

  if (SetupCost != Other.SetupCost)                         return SetupCost
< Other.SetupCost;

  return false;



If we have a case to compare

Cost at 5 regs, with addrec cost 1, plus 15 base adds, plus 1 imm cost, plus
4 setup cost.

Cost at 4 regs, with addrec cost 1, plus 28 base adds, plus 1 imm cost, plus
2 setup cost.

The current mode will select 4 regs case even there are 14 more base adds.
And base

Adds matters in our targets.


So I think the current LSR should be pushing more decision into target
dependent backend.

Like calling new functions in TargetTransformInfo. At least, in narrow
search space and cost 

comparison phase, or more in cost rating phase. LSR can be tightly cooped
with the target

attributes in order to get the most beneficial result.


How do you guys think?







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130313/72e8fb24/attachment.html>

More information about the llvm-dev mailing list