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

[Ulrich Weigand]

Alan Modra wrote:
> On Mon, Jul 11, 2016 at 03:26:46PM +0200, Ulrich Weigand wrote:
> > However, there still seems to be another underlying problem: reload
> > should never generate invalid instructions.  (Playing with '?' to
> > fix *inefficient* instructions is fine, but we shouldn't rely on '?'
> > to fix *invalid* instructions.)
> > 
> > If reload -for whatever reason- wants to emit a vr->gpr move, then it
> > should generate a valid instruction sequence to do so, via secondary
> > reloads if necessary.  I think it would be a good idea to investigate
> > why that isn't happening in this test case.  [ There is a chance that
> > the underlying bug will reappear in a different context, even after
> > the '?' change is applied. ]
> 
> The vr->gpr move uses secondary memory.  The memory allocated by
> assign_stack_local, called from get_secondary_memory is
> 
> (mem/c:V16QI (plus:DI (reg/f:DI 113 sfp)
>         (const_int 32 [0x20])) [0  S16 A128])
> 
> and that is incorrectly simplified by eliminate_regs to
> 
> (mem/c:V16QI (reg/f:DI 1 1))
> 
> for use by the strict_memory_address_space_p check, which of course
> then passes.
> 
> eliminate_regs sees this entry in the elimination table:
> (gdb) p *ep
> $7 = {from = 113, to = 1, initial_offset = -32, can_eliminate = 1, can_eliminate_previous = 1, offset = -32, previous_offset = -32, ref_outside_mem = 0, from_rtx = 0x7ffff688a300, to_rtx = 0x7ffff688a2e8}
> 
> The offset in the elimination table was correct before
> get_secondary_memory called assign_stack_local, but not after
> frame_offset was changed when allocating a new stack slot.

OK, I see.  Yes, the first time around that will be wrong.
However, if get_secondary_mem called assign_stack_local, the
stack size will be changing, which is why the main loop
around calculate_needs_all_insns() in reload() should set
the "something_changed" flag and restart the whole process.
(Which means the reloads for the first pass will be wrong,
but that doesn't matter since they will be ignored.)

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?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com