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

[Peter Bergner <bergner at vnet dot ibm dot com>]

On 7/12/16 8:48 AM, 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.

Catching up with email, not that I'm back from vacation.

This still doesn't answer David's question about what will happen if
we generate this pattern (or one of the older VSX reg+reg patterns)
when we are NOT using -mno-vsx.  In those cases, quad_address_p and
mode_supports_vsx_dform_quad will return true and it seems like
we'll go ahead and generate these reg+offset addresses when they're
not legal for these patterns.

As I said in my previous note, I wasn't able to actually generate the
altivec pattern (I haven't tried the vsx reg+reg patterns), but if we
could, I assume we'll still have the same issue, will we not?

Peter