From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@redhat.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: gcc@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: pa reload problem 
Date: Wed, 03 Jan 2001 20:57:00 -0000
Message-id: <9165.978583846@upchuck>
References: <200101020037.TAA26820@hiauly1.hia.nrc.ca>
X-SW-Source: 2001-01/msg00160.html

  In message < 200101020037.TAA26820@hiauly1.hia.nrc.ca >you write:
  > > (insn 1067 1063 2002 (set (reg/f:SI 403)
  > >         (mem/u:SI (lo_sum:SI (reg/f:SI 611)
  > >                 (unspec:SI[ 
  > >                         (symbol_ref:SI ("target_flags"))
  > >                     ]  0)) 0)) 69 {*pa.md:2099} (nil)
  > >     (expr_list:REG_EQUIV (mem/u:SI (lo_sum:SI (reg/f:SI 611)
  > >                 (unspec:SI[ 
  > >                         (symbol_ref:SI ("target_flags"))
  > >                     ]  0)) 0)
  > >         (expr_list:REG_DEAD (reg/f:SI 611)
  > >             (nil))))
  > 
  > The REG_EQUIV note gets added in local-alloc.c here:
  > 
  >       /* If this register is known to be equal to a constant, record that
  >          it is always equivalent to the constant.  */
  >      if (note && ! rtx_varies_p (XEXP (note, 0)))
  >        PUT_MODE (note, (enum machine_mode) REG_EQUIV);
  > 
  > The problem appears to be that the "constant" part of the lo_sum (the
  > symbol_ref) should be the first operand:
  > 
  >     case LO_SUM:
  >       /* The operand 0 of a LO_SUM is considered constant
  >          (in fact is it related specifically to operand 1).  */
  >       return rtx_varies_p (XEXP (x, 1));
  > 
  > This problem appears to prevalent in a number of places in pa.md and pa.c.
  > It looks like the argument order for lo_sums in hte pa port needs to be
  > switched.
Huh?  It follows the same convention as every other port that uses
HI and LO_SUM.

op0 is a register, but it is known to be a constant (the high part of
the expression found in op1).

jeff