This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Tue, 11 Jan 2005 20:38:50 +0000, Joern RENNECKE
<> wrote:

> in reload.c:find_reloads_toplev, look for this comment:
>           /* 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.
>          We also need to do this if there is an equivalent MEM that is
>          not offsettable.  In that case, alter_subreg would produce an
>          invalid address on big-endian machines.
>          For machines that extend byte loads, we must not reload using
>          a wider mode if we have a paradoxical SUBREG.  find_reloads will
>          force a reload in that case.  So we should not do anything
> here.  */
> 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.

That comment applies to this code:

		else if (regno >= FIRST_PSEUDO_REGISTER
		   && (GET_MODE_SIZE (GET_MODE (x))
		  && (reg_equiv_address[regno] != 0
			 || (reg_equiv_mem[regno] != 0
				&& (! strict_memory_address_p (GET_MODE (x), XEXP (reg_equiv_mem[regno], 0))
					 || ! offsettable_memref_p (reg_equiv_mem[regno])
					|| num_not_at_initial_offset))))
			x = find_reloads_subreg_address (x, 1, opnum, type, ind_levels,  insn);

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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]