Help with reload bug, please

Jeff Law law@redhat.com
Fri Jan 23 16:34:00 GMT 2015


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
> mode.


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+ 
address.

We may have used special constraints as well to allow loads/stores of 
integer registers in FP modes to use the larger offset.

Jeff





More information about the Gcc mailing list