On 25/01/17 09:29, Christophe Lyon wrote: > On 25 January 2017 at 10:18, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> > wrote: >> >> On 25/01/17 08:53, Christophe Lyon wrote: >>> >>> On 24 January 2017 at 18:15, Bernd Schmidt <bschm...@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). >
As discussed at the Cauldron, I'm working on fixing that, but it won't be until GCC-8 now. R. > >> Thanks, >> Kyrill >> >>>> Bernd >> >>
