This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improve things for PR71724, in combine/if_then_else_cond



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.

Thanks,
Kyrill

Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]