[llvm-dev] Strange behaviour of post-legalising optimisations(?)

[Joan Lluch via llvm-dev]

Hi Tim,

After studying the x86 backend I got it working !

What happens is that considering the following formulas:

reg({%dest,+,1}<nsw><%for.cond>) 
reg(%dest) + 1*reg({0,+,1}<nuw><nsw><%for.cond>)

the RateFormula function is designed to not increment the instruction counter when the second form appears more than once. This is what it gives it some cost advantage over the first form, as I wanted. Now, the x86 takes advantage of this by implementing an unique isLSRCostLess function on its TargetTransformInfo. The isLSRCostLess function compares costs for the Loop Strength Reduction algorithm and there’s a hook to custom implement it. The particular implementation of x86 is the only one (along with the SystemZ) that takes the number of instructions into account and puts that as main cost. All the other targets just rely on the default isLSRCostLess implementation that takes number of registers as priority. So that was it.

So thanks for all your pointers!

Joan Lluch



> On 6 Jun 2019, at 16:42, Tim Northover <t.p.northover at gmail.com> wrote:
> 
> Hi,
> 
> On Thu, 6 Jun 2019 at 07:28, Joan Lluch <joan.lluch at icloud.com> wrote:
>> So any additional help would be appreciated.
> 
> I'm not terribly familiar with the code involved, but I did notice x86
> (which doesn't have post-increment addressing either) managed to avoid
> the form you don't want. So perhaps seeing where it diverges from your
> path would be a good starting point.
> 
> Cheers.
> 
> Tim.