On 08/07/2018 02:11 PM, Richard Sandiford wrote:
> Hi Vlad,
>
> Thanks for the patch.
>
> Vlad Lazar <vlad.la...@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
