virtual-stack-vars reference not resolved in vregs

[Segher Boessenkool]

On Fri, May 25, 2018 at 08:11:43AM +0200, Eric Botcazou wrote:
> > Is this something the back end is responsible for getting right, for example
> > via the machine description file?  If so, any hints where to start?
> 
> The SUBREG of MEM is invalid at this stage.

>From rtl.texi:

---
There are currently three supported types for the first operand of a
@code{subreg}:
@itemize
@item pseudo registers
This is the most common case.  Most @code{subreg}s have pseudo
@code{reg}s as their first operand.

@item mem
@code{subreg}s of @code{mem} were common in earlier versions of GCC and
are still supported.  During the reload pass these are replaced by plain
@code{mem}s.  On machines that do not do instruction scheduling, use of
@code{subreg}s of @code{mem} are still used, but this is no longer
recommended.  Such @code{subreg}s are considered to be
@code{register_operand}s rather than @code{memory_operand}s before and
during reload.  Because of this, the scheduling passes cannot properly
schedule instructions with @code{subreg}s of @code{mem}, so for machines
that do scheduling, @code{subreg}s of @code{mem} should never be used.
To support this, the combine and recog passes have explicit code to
inhibit the creation of @code{subreg}s of @code{mem} when
@code{INSN_SCHEDULING} is defined.
---

It would be very nice if we got rid of subreg-of-mem completely once and
for all.

The code following the comment
  /* In the general case, we expect virtual registers to appear only in
     operands, and then only as either bare registers or inside memories.  */
in function.c:instantiate_virtual_regs_in_insn does not handle the subreg
in this example instruction.


Segher