[llvm-dev] LSR formula rating

[Krzysztof Parzyszek via llvm-dev]

I have a few questions regarding cost calculation in loop strength 
reduction.

1. Ignoring LSR uses of kind ICmpZero.
These usually come from the loop latch conditions. On Hexagon most loops 
that would contain such a LSR use are going to be converted to hardware 
loops and the entire check will disappear. There is no need to analyze 
these cases in LSR. In fact, completely ignoring them improves 
performance. Would it be reasonable to add a target hook to check if the 
target wants to ignore these? I suppose this could apply to other target 
with hardware loop support.

2. C.SetupCost
What it the motivation behind this code?
   // Rough heuristic; favor registers which don't require extra setup
   // instructions in the preheader.
   if (!isa<SCEVUnknown>(Reg) &&
       !isa<SCEVConstant>(Reg) &&
       !(isa<SCEVAddRecExpr>(Reg) &&
         (isa<SCEVUnknown>(cast<SCEVAddRecExpr>(Reg)->getStart()) ||
          isa<SCEVConstant>(cast<SCEVAddRecExpr>(Reg)->getStart()))))
     ++C.SetupCost;
I'd imagine that this accounts for the extra code that needs to be 
added, but why is it what it is? After extra formulas are generated, 
some of them can contain constants that were not in the code before and 
thus may require an instruction to put them into a register, yet for 
constants the SetupCost will be 0. On a similar note, are SCEVUnknowns 
presumed to already have a register?

3. isLegalAddressingMode
There are many addressing modes that are legal on Hexagon, yet given a 
choice, some are preferable to others. LSR treats all of them as 
equivalent as long as a formula can be folded completely into it. Has 
anyone thought about making the cost of an addressing mode be more detailed?

4. RateFormula
A lot of that code looks rather mysterious. Is there a document that was 
the original inspiration?


-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation