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
