This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-64 on HP-UX 11.00
- From: law at redhat dot com
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: h dot m dot brand at hccnet dot nl, gcc-patches at gcc dot gnu dot org
- Date: Fri, 17 May 2002 18:31:23 -0600
- Subject: Re: gcc-64 on HP-UX 11.00
- Reply-to: law at redhat dot com
In message <200205172249.g4HMnYfC000195@hiauly1.hia.nrc.ca>, "John David
Anglin" writes:
> But in this case, we don't need the address of the MEM. The pattern at
> line 2234 in pa.md 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
be,l.
If we're not accepting be,l, then that would be a gas bug and it needs to be
fixed.
> --- pa.h.save 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.
jeff