This is the mail archive of the 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: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx

On Tue, Jul 12, 2016 at 04:17:23PM +0200, Ulrich Weigand wrote:
> Alan Modra wrote:
> > The problem now is that this passes rs6000_legitimate_address_p due to
> > mode_supports_vsx_dform_quad and quad_address_p being true.  That
> > doesn't seem correct for -mno-vsx.
> Hmm, I see in rs6000_option_override_internal:
>   /* ISA 3.0 D-form instructions require p9-vector and upper-regs.  */
>     {
>       if (rs6000_isa_flags_explicit & OPTION_MASK_P9_VECTOR)
>         error ("-mpower9-dform requires -mpower9-vector");
>       rs6000_isa_flags &= ~(OPTION_MASK_P9_DFORM_SCALAR
>                             | OPTION_MASK_P9_DFORM_VECTOR);
>     }
> and *later*:
>   /* ISA 3.0 vector instructions include ISA 2.07.  */
>     {
>       if (rs6000_isa_flags_explicit & OPTION_MASK_P8_VECTOR)
>         error ("-mpower9-vector requires -mpower8-vector");
>       rs6000_isa_flags &= ~OPTION_MASK_P9_VECTOR;
>     }
> That seems the wrong way around ...

Yes, your analysis agrees with mine.  Putting these overrides in the
correct order will result in -mno-vsx forcing -mno-power9-dform (via
-mno-power8-vector and -mno-power9-vector).  With that in place, the
address predicates give the correct answer, and what's more, result in
reload costing altivec_mov alternatives the way we'd expect without
any changes to altivec_mov.

Incidentally, disparaging altivec_mov alternatives as I did in cause
testsuite regressions on powerpc64le-linux.

Alan Modra
Australia Development Lab, IBM

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