This is the mail archive of the gcc@gcc.gnu.org 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]

Re: pa reload problem


  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

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