[PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx

[Alan Modra]

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 ((TARGET_P9_DFORM_SCALAR || TARGET_P9_DFORM_VECTOR) && !TARGET_P9_VECTOR)
>     {
>       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 (TARGET_P9_VECTOR && !TARGET_P8_VECTOR)
>     {
>       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
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00475.html cause
testsuite regressions on powerpc64le-linux.

-- 
Alan Modra
Australia Development Lab, IBM