Re: gcc-64 on HP-UX 11.00

[law at redhat dot com]

 In message <200204162223.g3GMNlk9012415@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 > > FP register to hold an address like this is an exceedingly bad thing to
 > > do.  In fact, not assigning the value to a register and instead leaving it
 > > in memory is actually cheaper than assigning it to an FP register.
 > 
 > I don't quite follow that logic.  Two insns are needed to load the
 > address and the result must end up in a register.  You can't load
 > the address directly to memory.  It takes a couple of insns to copy
 > the result from the FP register to a general register.  Generally,
 > I guess this must be weighed against the cost of freeing up a general
 > general.
 > 
 > > In fact, from the fragments, it looks like we did something insanely stupi
 > d,
 > > why don't we assign the value to %r28 or %r25?
 > 
 > I agree it seems very dumb.  We have the following rtl at the end of
 > function after lreg:
 > 
 > (insn 3088 3494 3091 (set (reg/i:DI 28 %r28)
 >         (reg/f:DI 66)) 119 {*pa.md:3106} (nil)
 >     (expr_list:REG_DEAD (reg/f:DI 66)
 > 	(nil)))
 > 
 > DI 66 is set in multiple places.  It seems the compiler doesn't
 > recognize opportunities to replace DI 66 with DI 28, and so on.
 > 
 > Jeff, I will send you gv.i offline so that you can look at the problem
 > in more detail.
Thanks.  Here's the patch that allows me to compile gv.i without any
problems.  I've bootstrapped both 32bit and 64bit.  I've built perl
both 32bit and 64bit.

I've also examined the register costing for gv.i and it looks a hell of
a lot better.  With an older PA64 compiler (which exhibits this bug) I
end up with 25 registers that prefer FPREGS or GENERAL_OR_FP_REGS,
including the problematical pseudos we've been looking at.

With my fix only only 9 registers want FPREGS or GENERAL_OR_FP_REGS and
they're all reasonable requests for those classes.

I've got a dentist appointment shortly, so I won't be able to do any
additional testing today.  I'll probably be busy as hell tomorrow too.

I'm pretty confident the patch is correct, but you indicated you went
down this path and it didn't sound like you had much success (though it
appeared you made other changes in how 'T' has handled).

Anyway, here's the patch.  I'll leave it up to you to decide if we want
to recommend this for 3.1.

jeff


	* pa.h (EXTRA_CONSTRAINT): Don't accept PIC addresses for the
	'T' constraint.

Index: pa.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/pa/pa.h,v
retrieving revision 1.138.2.4
diff -c -3 -p -r1.138.2.4 pa.h
*** pa.h	26 Apr 2002 18:40:47 -0000	1.138.2.4
--- pa.h	1 May 2002 17:13:32 -0000
*************** extern int may_call_alloca;
*** 1238,1243 ****
--- 1238,1244 ----
  			     ? GET_MODE (OP)		\
  			     : DFmode),			\
  			    XEXP (OP, 0))		\
+        && GET_CODE (XEXP (OP, 0)) != LO_SUM		\
         && !(GET_CODE (XEXP (OP, 0)) == PLUS		\
  	    && (GET_CODE (XEXP (XEXP (OP, 0), 0)) == MULT\
  		|| GET_CODE (XEXP (XEXP (OP, 0), 1)) == MULT)))\