Re: Bug on PA-RISC

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

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

I'll will try to put this together.  I observered this in the dumps 
from f/data.c.  When I saw that reload was creating an insn to copy
the DImode value from one FPR to another, I realized why this copy
was disparaged in other similar patterns.

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

OK.  My observations were with "-mpa-risc-2-0".

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

I didn't see this in all cases.  I saw

(set (GPR) (mem:SI (lo_sum ...)))
(set (mem: (stack location)) (GPR))
(set (FPR1) (mem: (stack location)))

Again, this was with dumps from f/data.c under hppa-linux.  I had
changed the predicates for the xmpyu pattern to register operand,
so the first set of reloads weren't needed.  Is there something
subtle about the operation of reload which changes the way it
behaves for primary and secondary reloads?

Regarding the xmpyu insn, it only works with floating register arguments.
I thought changing the operands of the pattern to register_operand is a more
accurate description of the machine insn although reloads still can
potentially occur.

I think that we would get better floating point code if it were not
necessary to disparage floating point register copies.

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