Re: How to handle subreg(mem(X)) after reload?

[Robert Baruch <autophile at gmail dot com>]

On Tue, 11 Jan 2005 18:47:22 -0500, Robert Baruch <autophile@gmail.com> wrote:
> On Tue, 11 Jan 2005 20:38:50 +0000, Joern RENNECKE
> <joern.rennecke@st.com> wrote:
> 
> >           /* If the subreg contains a reg that will be converted to a mem,
> >          convert the subreg to a narrower memref now.
> >          Otherwise, we would get (subreg (mem ...) ...),
> >          which would force reload of the mem.

> > Code that runs in-between find_reloads and the alteration of all pseudos
> > into hard
> > regs has to be careful not to produce a subreg of a reg that will get
> > replaced by a mem.
> 
> Yes, I saw that comment as well, and traced the code through, and it
> looked like GCC failed to convert the subreg.
> 
> When I traced it through for the instruction with the subreg(pseudo),
> reg_equiv_address was 0, reg_equiv_mem was [FP+104],
> strict_memory_address_p(QImode, FP+104) ended up being 1,
> offsettable_memref_p( [FP+104] ) was also 1, and
> num_not_at_initial_offset was 0.
> 
> All that means is that find_reloads_subreg_address is simply not called.
> 
> That just didn't make any sense to me. It seems to me that if the
> memory address corresponding to the pseudo is valid, AND the memory
> reference is offsettable (i.e. FP+104+x is valid) then the subreg
> should be narrowed. The logic just seems inverted to me.
> 
> What should be happening in this case to force
> find_reloads_subreg_address to be called?

Well, I've been staring and staring at the GCC code, and I still
can't, for the life of me, figure out where GCC will prevent
subreg(mem) from being created. Is it something that I should be doing
to prevent subreg(mem) when it is created out of subreg(pseudo)?

Thanks,

--Rob