Improve things for PR71724, in combine/if_then_else_cond
Christophe Lyon
christophe.lyon@linaro.org
Wed Jan 25 10:01:00 GMT 2017
On 25 January 2017 at 10:18, Kyrill Tkachov <kyrylo.tkachov@foss.arm.com> wrote:
>
> On 25/01/17 08:53, Christophe Lyon wrote:
>>
>> On 24 January 2017 at 18:15, Bernd Schmidt <bschmidt@redhat.com> wrote:
>>>
>>> On 01/24/2017 06:03 PM, Christophe Lyon wrote:
>>>>
>>>> Ha... the regression occurred between r 244818 and r 244816,
>>>> and I read r 244816 ChangeLog too quickly and did not notice
>>>> it was modifying ifcvt.c in addition to x86-only files.
>>>>
>>>> So it's likely that it's your other patch for pr78634
>>>> that caused the regression I mentioned. Does it make
>>>> more sense?
>>>
>>>
>>> That's possible. That added a missing cost check, so the question becomes
>>> -
>>> is the change in generated assembly sensible, given the selected CPU
>>> type?
>>>
>> I can now confirm that the change is indeed caused by r244816 (pr78634).
>> The difference in the generated asm is:
>> - vmov d17, r0, r1
>> - vmov d16, r2, r3
>> - vcmp.f64 d17, d16
>> + vmov d16, r0, r1
>> + vmov d17, r2, r3
>> + vcmp.f64 d16, d17
>> vmrs APSR_nzcv, FPSCR
>> - vselvs.f64 d16, d16, d17
>> + vmovvs.f64 d16, d17
>>
>> which, besides swapping d16 and d17, summarizes to
>> - vselvs.f64 d16, d16, d17
>> + vmovvs.f64 d16, d17
>>
>> I'm not sure if there is a "best" one ?
>>
>
> The test is supposed to test the generation of the vsel instruction.
> I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
> VSEL isn't actually available on Cortex-A5, it's just enabled by the
> -mfpu=fp-armv8 option.
> A more realistic configuration would target an ARMv8-A CPU like the
> Cortex-A57.
>
Yes indeed, it's always confusing to be able to provide "incompatible"
-mcpu and -mfpu flags (as in: no such combination actually exists).
> Thanks,
> Kyrill
>
>>> Bernd
>
>
More information about the Gcc-patches
mailing list