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
