Help with reload bug, please

[Andrew Stubbs]

On 23/01/15 16:34, Jeff Law wrote:
> 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.

Yes, that seems similar.

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

This is already the case; it does the right thing when the mode is SFmode.

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

SECONDARY_INPUT_RELOAD_CLASS is another missed opportunity. Just like 
the legitimate address stuff, this has checks for the various VFP 
classes, but reload detects the class in the same flawed way, so an 
integer reload gives GENERAL_REGS even when the destination is VFP. 
Within the macro there's no way to see the whole insn.

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

Do you have an example?

Thanks

Andrew