This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc-64 on HP-UX 11.00

 In message <>, "John David 
Anglin" writes:
 > But in this case, we don't need the address of the MEM.  The pattern at
 > line 2234 in can handle the secondary reload of the MEM (2nd last
 > alternative) if we change the T constraint to allow non-pic LO_SUMs.
It's not the movsi pattern that is the problem.  The problem is the 
xmpyu patterns.  I'm not sure why you're thinking about the movsi pattern
at all for this problem.

If we have a MEM as an input operand for xmpyu, then we need at the minimim
a FPR reload reg and possibly a GPR secondary reload reg.  Similarly if we
have a MEM as the output operand.  secondary_reload_class is responsible for
determining when we need that secondary reload register.

 > This allows the MEM to get directly loaded into the FPR for the xmpyu.
 > Isn't it just the pic case that the pattern can't handle?
Not necessarily.  Consider an out of range stack slot.  You need a secondary
register for that.  You also need a secondary register if the memory address
for PIC.

 > I enclose below my current fixes for the pa-risc-2-0 boot problems.
 > GAS doesn't understand "be,l"!  The two "xmpyu" patterns with operand 2
 > "uint32_operand" seem suspect to me.  They will need a reload so
 > maybe they should be deleted.
For the old style syntax the proper way is "ble".  For new syntax you would use

If we're not accepting be,l, then that would be a gas bug and it needs to be

 > ---	Fri May 17 08:33:57 2002
 > +++ pa.h	Fri May 17 10:56:22 2002
 > @@ -1243,7 +1243,9 @@ extern int may_call_alloca;
 >  			     ? GET_MODE (OP)		\
 >  			     : DFmode),			\
 >  			    XEXP (OP, 0))		\
 > -       && GET_CODE (XEXP (OP, 0)) != LO_SUM		\
 > +       && !(GET_CODE (XEXP (OP, 0)) == LO_SUM		\
 > +	    && GET_CODE (XEXP (XEXP (OP, 0), 0)) == REG	\
 > +	    && GET_CODE (XEXP (XEXP (OP, 0), 1)) == UNSPEC)\
 >         && !(GET_CODE (XEXP (OP, 0)) == PLUS		\
 >  	    && (GET_CODE (XEXP (XEXP (OP, 0), 0)) == MULT\
 >  		|| GET_CODE (XEXP (XEXP (OP, 0), 1)) == MULT)))\
What's the point behind this change?  We want to reject any LO_SUM here, so
it seems silly to check for LO_SUM (REG) or LO_SUM (UNSPEC).  Just leave it
as is and reject all LO_SUMs.

And yes, the uint32_operands are very suspicious.  I wouldn't lose any sleep
if that stuff was cleaned up.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]