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

[Andrew Trick]

On Mar 13, 2013, at 4:37 PM, Yin Ma <yinma at codeaurora.org> wrote:

> 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 considering
> the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs)
> 2.       Cost comparison solely favors the number register without considering other
> Impacts.
>  
> For the case one,
> NarrowSearchSpaceByPickingWinnerRegs filters by most occurred registers.
> ld(basereg, immediate) is a target preferred addressing mode. However, it may
> be deleted because basereg is very likely not to be the most occurred register
> 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 < Other.NumRegs;
>   if (AddRecCost != Other.AddRecCost)                  return AddRecCost < Other.AddRecCost;
>   if (NumIVMuls != Other.NumIVMuls)                   return NumIVMuls < Other.NumIVMuls;
>   if (NumBaseAdds != Other.NumBaseAdds)       return NumBaseAdds < Other.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.

Yes. LSR decisions are tightly coupled with the target architecture and potentially the subtarget microarcthitecture. As you figured out, the way to handle it is to communicate more information to LSR through TTI. It's easy to do this to solve individual benchmarks on your target. It's hard to know if you have a general solution that works across targets. But if you can add hooks in a way that preserves existing behavior on other targets it shouldn't be a problem. We want to design general hooks, but leave it up to someone doing the benchmarking to tune them for a particular target.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130314/d9770336/attachment.html>