Re: Bug on PA-RISC

[law at redhat dot com]

In message <200205310608.g4V68pXW004677@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 > Jeff,
 > 
 > Here is a fix for the LO_SUM bug which we discussed before I went away.
 > It's corrects a "typo" in the DImode move pattern.  The correction
 > is consistent with the approach used elsewhere to correct the problem
 > (ie., severely disparage copies from one floating register to another).
 > However, I must say that I don't like the fix as it causes really
 > bad code to be generated (load MEM to general register, then back
 > to stack, and then finally to FPR register).
Yea.  When I started poking at this, it became immediately clear why those
patterns operate the way they do -- when you write them in what should be
the clean and simple way, you get lousy code.

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.

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.

  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.

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.

 >  Not sure whether
 > cse2 will do the combine if the source/target is a general register.
 > The asymmetric behavor of the instruction set with respect to
 > the floating and general registers is a pain.
The asymmetric nature of memory operands in general on the PA has been
a huge problem over the years.  Conceptually GCC wants to be able to say
"is this a valid memory operand?".  It doesn't care if it's a load or store,
or what register file is going to be used.  

If you restrict yourself to that model, then you really pessimize code, both
integer and FP.  We've gone through numerous hoops to actually be able to
use the larger displacements available in integer loads/stores, indexing
loads to integer registers, etc etc.  But it's made for some complex and
unwieldy code in pa.c/pa.h.  Particularly in the constraints and address
checking.

 > I've tested the patch under hppa2.0w-hp-hpux11.11 with "-mpa-risc-2-0"
 > in BOOT_CFLAGS.  There are still some fails that aren't there without
 > the option.  For example,
I've got a few more tests to do with my patch.  So far I've got:

 PA1.1 3-staged & regression tested

 PA2.0 3-staged & regression tested

 PA64  3-staged, regression testing in progress

 Perl -- will need to re-test with PA1.1, PA2.0 and PA64.

What a pain.

jeff