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
