Bug on PA-RISC

[John David Anglin]

> So the predicates for those patterns allow some stuff that isn't strictly
> allowed by the instruction and arrange via the constraints to have any
> problematical values reloaded into a floating point register.

Exactly.  We wouldn't need to disparge the floating point to floating point
register copy if reload wasn't so stupid.  Currently, when it finds the
symbolic mem value that can't be loaded directly to a FPR register, it
creates a new insn to load the value to a different FPR register (when
copies aren't disparaged) and then copies the value in the new FPR
register to the old FPR register.  It doesn't recognize that the new
insn that it has created has the same problem as the old one.  Somehow,
we need to get reload to use the address of the MEM when it needs to
reload a LO_SUM MEM.

> 
> When the input is the contents of a symbolic memory location we have several
> cases to consider.
> 
>   PA1.1 Normal  Address will be load into a GPR and we'll load the data
> 	        from memory into an FPR.

The problem here is cse/combine will insert the address load insn into the
data load insn.  If the load is for a GPR, this is fine.  If it's for a
FPR, then the combination creates a problem for reload, except for PA2.0
after 32bit assembler is fixed.  I don't know how to distinguish
the two situations because the register allocation is done after the
combine.

>   PA1.1 PIC     Similar.  Only difference is the code to load the address
> 	        into the GPR is more complex.
> 
>   PA2.0 Normal  We can load from (mem (lo_sum ..)) directly into an FPR.
>                 This is the way the code was supposed to work; I botched it
>                 when fixing the PA64 perl bug for GCC 3.1.  Sigh.
>                 
>   PA2.0 PIC     Address loaded into GPR, data loaded from memory into FPR.
> 
> 
>   PA64          PA64 is PIC and will be handled by loading the address into
>                 a GPR, then loading the data from memory into the FPR.
> 
> 
> You mentioned a gas/ld problem with PA2.0 with handling the larger 
> displacements
> in FP loads/stores.  Presumably this is only a problem for elf32-hppa.c since
> it works fine for SOM and PA64 to the best of my knowledge.

That is likely the case.  The problem was noted with elf32-hppa.c under
hppa-linux.  This is the thread
<http://sources.redhat.com/ml/bug-binutils/2002-q2/msg00289.html>.

> 
> BTW, the uint32_operand variants were to allow for efficient loading of a
> constant for use in an xmpyu instruction.    Otherwise we build the constant
> into a GPR, store it into a stack slot, load it from the stack
> slot into an FPR and use it.  With the uint32_operand variant, the suitable
> constant will already be sitting in memory and we can load it directly into
> the FPR (saving a memory store).
> 
>  > There must be a better way.  Possibly, we could delay allowing
>  > LO_SUM MEMs in the pattern until after reload?
> I suspect this is ultimately going to lose too.  You'll end up with a DImode
> load somewhere that is later used in the xmpyu pattern.  I suspect the DImode
> load will end up prefering a GPR while we need an FPR for the xmpyu and
> you'll get the GPR->mem->FPR mess unconditionally.

Could be :-(

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)