This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR 24621 (find_reloads problem)
- From: Ian Lance Taylor <ian at airs dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, rth at redhat dot com
- Date: 03 Nov 2005 21:59:20 -0800
- Subject: Re: [PATCH] Fix PR 24621 (find_reloads problem)
- References: <200511032353.jA3NrE73001332@53v30g15.boeblingen.de.ibm.com>
Ulrich Weigand <uweigand@de.ibm.com> writes:
> Actually, I think this is not just a heuristic, but the documented
> interface for the back-end to decide which constants to force.
>
> From tm.texi:
> One case where @code{PREFERRED_RELOAD_CLASS} must not return
> @var{class} is if @var{x} is a legitimate constant which cannot be
> loaded into some register class. By returning @code{NO_REGS} you can
> force @var{x} into a memory location.
OK, fair enough.
...
> If we follow that argument, the current proposed patch is just the
> logical conclusion -- we definitely need to handle SUBREG (PLUS)
> reloads the same as PLUS reloads here.
I agree that if your older patch should stay, then your newer patch is
correct.
...
> But even if calling find_reloads_address *is* the right way, we'd still
> end up most likely in find_reloads_address_part, which uses the same
> logic to decide to force the constant anyway ...
The main difference being that there is a target hook first via
LEGITIMIZE_RELOAD_ADDRESS, and that target hook will have special
handling for stack frame addresses when that is useful.
Ian