This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [reload] paradoxical mems
- From: Ian Lance Taylor <ian at airs dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 12 Jan 2006 19:59:41 -0800
- Subject: Re: [reload] paradoxical mems
- References: <200601130208.k0D285s5017878@greed.delorie.com>
DJ Delorie <dj@redhat.com> writes:
> reg_overlap_mentioned_for_reload_p() assumes that all SUBREGs
> have REGs as their operand. However, register_operand() has
> this comment:
>
> (Ideally, (SUBREG (MEM)...) should not exist after reload,
> but currently it does result from (SUBREG (REG)...) where the
> reg went on the stack.) */
>
> When this happens during reload, reg_overlap_mentioned_for_reload_p()
> blindly takes the REGNO of a MEM and later on aborts. The patch below
> at least treats (subreg (mem)) the same as (mem) for this function,
> and gcc does the right thing later on anyway. The question is: does
> finding a (subreg (mem)) at this point indicate that something is
> wrong with my port (m32c)? Or is reload actually wrong here? If
> reload is wrong, is this the right way to deal with these?
Reload can temporarily produce a SUBREG of a MEM if, as the comment
says, the insn has a SUBREG of a REG, and the REG is turned into a
memory address. But before approving this patch, can you say
something about what calls reg_overlap_mentioned_for_reload_p in this
case? There are a number of places in reload which assume that a
SUBREG is only of a REG.
Ian