Re: [RFC][PATCH][mid-end] Optimize immediate choice in comparisons.

[Jeff Law <law at redhat dot com>]

On 08/07/2018 02:11 PM, Richard Sandiford wrote:
> Hi Vlad,
> 
> Thanks for the patch.
> 
> Vlad Lazar <vlad.lazar@arm.com> writes:
>> Hi.
>>
>> This patch optimises the choice of immediates in integer comparisons. Integer
>> comparisons allow for different choices (e.g. a > b is equivalent to a >= b+1)
>> and there are cases where an incremented/decremented immediate can be loaded into a
>> register in fewer instructions. The cases are as follows:
>>    
>> i)   a >  b or a >= b + 1
>> ii)  a <= b or a <  b + 1
>> iii) a >= b or a >  b - 1
>> iv)  a <  b or a <= b - 1
>>
>> For each comparison we check whether the equivalent can be performed in less instructions.
>> This is done on a statement by statement basis, right before the GIMPLE statement is expanded
>> to RTL. Therefore, it requires a correct implementation of the TARGET_INSN_COST hook.
>> The change is general and it applies to any integer comparison, regardless of types or location.
>>
>> For example, on AArch64 for the following code:
>>
>> int foo (int x)
>> {
>>    return x > 0xfefffffe;
>> }
>>
>> it generates:
>>
>> mov	w1, -16777217
>> cmp	w0, w1
>> cset	w0, cs
>>
>> instead of:
>>
>> mov	w1, 65534
>> movk	w1, 0xfeff, lsl 16
>> cmp	w0, w1
>> cset	w0, hi
>>
>> Bootstrapped and regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and there are no regressions.
> 
> Looks like a useful feature.  I'm playing devil's advocate to some
> extent here, but did you consider instead doing this during the
> expansion functions themselves?  In some ways that feels more
> natural because we're already operating on rtxes at that point.
> It also has the advantage that it would trap comparisons that didn't
> exist at the gimple level, such as when computing the carry for a
> doubleword add/sub.
I've got no strong opinions on doing it in cfgexpand vs the expansion
functions themselves.  I'm happy to have you setting overall direction
here Richard.

I do worry about the amount of RTL we generate and throw away during
cost computation.  Though it's just for comparisons, so it may not be
terrible.

I wouldn't be surprised if ports aren't particularly accurate in their
costing computations for this kind of use -- but that's nothing new.  We
run into it every time we use rtx costing in a new place.  I'm
comfortable having targets fault in improvements for this kind of use.

Jeff