Alan Modra wrote:
> On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
> > The second time around, get_secondary_mem should reuse the
> > same stack slot it already allocated, and the elimination
> > offsets should already be set to accommodate that stack slot,
> > which means the second time around, the correct RTX should be
> > generated for the memory access.
> >
> > Is this not happening somehow?
>
> Duh, yes, of course. Second time around the mem is
> (mem/c:V16QI (plus:DI (reg/f:DI 1 1)
> (const_int -16 [0xfffffffffffffff0])) [0 S16 A128])
> so we're checking the correct offset.
>
> 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 ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
[email protected]
