Bug on PA-RISC

[law@redhat.com]

In message <200206042151.g54LpVPf016686@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > > 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.
Please do. I'd like to take a look at it.

 [ ... ]
 > > understanding precisely what you think doesn't work properly in this case.
 > 
 > OK.  My observations were with "-mpa-risc-2-0".
OK.  Your commentary made me think you refering to PA1.1.  So the scenario
for PA2.0 would be:

 > > 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))
For PA2.0 we can load (mem:SI (lo_sum ...)) into an FPR, so we'd just stop
here and generate the insns noted above.

 > > 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)))
There may be ways to get this.  But this is precisely why getting the .lreg
and .greg dumps is so important.  We need to know what the insn looked like
before and after register allocation as well as the reload debugging 
information
that is dumped in to the .greg file.  Without that there's no real way to
know why you got that kind of code and if there's anything that can be done
about it.

[ I can envision several ways we might get that code, but they'd all be
  guesses.  It's not real useful to guess when we can get the hard data
  pretty easily. ]

 > 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.
What that probably did was cause us to prefer a GPR for the pseudos
rather than an FPR.  We then allocated the pseudos to the GPR, but
had to copy them to an FPR using the sequence noted above.  Avoiding
this kind of scenario is one of the reasons why the code is written
the way it is.

 > Is there something
 > subtle about the operation of reload which changes the way it
 > behaves for primary and secondary reloads?
I have no idea what you're asking here.

 > Regarding the xmpyu insn, it only works with floating register arguments.
Right.

 > 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.
It's certainly more accurate, but due to secondary effects of register 
allocation
and reloading it's actually more profitable to be more general in the 
operand predicates than what the instruction actually allows.  That is
generally a bad thing to do, but from time to time it is helpful.

 > I think that we would get better floating point code if it were not
 > necessary to disparage floating point register copies.
We only disparage them in integer modes -- which IMHO is the right thing
to do.  We only want to use FP registers for integer thingies when doing
xmpyu.  

jeff