Re: Bug on PA-RISC

[law at redhat dot com]

In message <200206042048.g54KmJk6016494@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > 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.
This would be a bug in how we handle secondary reloads somehow, and while
it's possible that we have such a bug, I'd really need more information
(dumps, particularly the .lreg and .greg dumps) to figure it out.


 > > When the input is the contents of a symbolic memory location we have sever
 > al
 > > 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.
We must be talking past each other -- this has worked for about 10 years
on PA1.1.  RTL dumps and reload dumps would be a big step forward in
understanding precisely what you think doesn't work properly in this case.

If we have something which matches this pattern

(define_insn "umulsidi3"
  [(set (match_operand:DI 0 "nonimmediate_operand" "=f")
        (mult:DI (zero_extend:DI (match_operand:SI 1 "nonimmediate_operand" 
"f"))
                 (zero_extend:DI (match_operand:SI 2 "nonimmediate_operand" 
"f"))))]
  "TARGET_PA_11 && ! TARGET_DISABLE_FPREGS && ! TARGET_SOFT_FLOAT"
  "xmpyu %1,%2,%0"
  [(set_attr "type" "fpmuldbl")
   (set_attr "length" "4")])

Where the input operands are of the form:

(mem:SI (lo_sum ...))

That triggers an input reload into an FPR.  ie, conceptually reload will
want to do something like this

(set (FPR1) (mem:SI (lo_sum ...))
(set (FPR2) (mem:SI (lo_sum ...))
(set (target) (mult:DI (zero_extend:DI (FPR1) (FPR2))

The first two insns will trigger a secondary reload which should require a GPR
register.  That will result in

(set (GPR) (lo_sum ...))
(set (FPR1) (mem (GPR))
(set (GPR) (lo_sum ...))
(set (FPR2) (mem (GPR))
(set (target) (mult:DI (zero_extend:DI (FPR1) (FPR2))

This should work as-is with the current sources.

 > > in FP loads/stores.  Presumably this is only a problem for elf32-hppa.c si
 > > 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>.
Then hppa-linux will need to have a flag to disable (mem:[SF,DF] (lo_sum ...))


jeff