This is the mail archive of the
mailing list for the GCC project.
Re: Help with reload bug, please
- From: Jeff Law <law at redhat dot com>
- To: Andrew Stubbs <ams at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 23 Jan 2015 09:34:25 -0700
- Subject: Re: Help with reload bug, please
- Authentication-results: sourceware.org; auth=none
- References: <54C2509C dot 2050908 at codesourcery dot com>
On 01/23/15 06:46, Andrew Stubbs wrote:
How does reload ensure that an SImode value (re)loaded into an FP
register has a valid stack index?
The FP load instruction allows a smaller index range than the integer
equivalent, but nothing checks the destination register, only the source
Unfortunately, GCC is designed with the assumption that the validity of
an address is independent of whether its used in a load or store and in
the case of a load, it's independent of the target register or in a
store that validity is independent of the source register.
This is deeply baked into the compiler in a variety of places. When I
had responsibility for the PA I bumped up against this often.
Just for reference, the PA allows a 14 bit displacement in memory
addresses which use integer registers, but only a 5 bit displacement for
FP registers. Other than the displacement amounts, I suspect this is
the same core problem you have on your port.
Ultimately all I could do way layer hack on hack. I can't remember them
all. The most significant ones were to first reject the larger offsets
for FP modes in GO_IF_LEGITIMATE_ADDRESS. While it's still valid (and
relatively common on the PA) to access integer registers in FP modes or
vice-versa, this change was a huge help.
Secondary reloads are critical. When you detect a situation that won't
work, you have to allocate a secondary reload register so that you can
build up the address as well as all the reload_in/reload_out handling.
This is how you ensure that if the compiler did something like try to
load from memory using an integer mode into an FP register you've got an
scratch register for reloading the address if it is an out-of-range reg+
We may have used special constraints as well to allow loads/stores of
integer registers in FP modes to use the larger offset.