Re: pa reload problem

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

>   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).

The problem is that it is "constant" but not invariant.  I was wrong
about the reversal, being confused by the fact that on the pa op1
is either a constant or symbol reference.  Thus, it didn't make much
sense to test op1 of a lo_sum in rtx_varies_p.  I had looked at the
documention but this convention is only documented in the code.

In this particular situation, the op0 register dies and the hard register
that reload asigns to it is reused.  However, reload doesn't check for this
and still goes ahead and substitutes the mem to eliminate the "equivalent"
pseudo.  My impression is that it would be easier to not create the REG_EQUIV
notes in local-alloc after the op0 register dies than fix the problem in
reload.  It appears that reload may substitute a mem for a psuedo whenever it
finds such a note without much testing.

If the REG_EQUIV notes aren't created, it is possible that it may not be
necessary to merge the special pic load insns into the insn which handles
move_operands because the op0 register will always die in the lo_sum insn
and the mem will not be substituted by reload.

I was working on a patch to local-alloc but after updating to the current
cvs today, I find the pa port doesn't build even without -fPIC:

./xgcc -B./ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -isystem /usr/local/hppa1.1-hp-hpux10.20/include -O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g1  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -DUSE_COLLECT2 -DL_fixunstfdi -c ../../gcc/libgcc2.c -o libgcc/./_fixunstfdi.o
../../gcc/libgcc2.c: In function `__fixunstfdi':
../../gcc/libgcc2.c:865: Internal compiler error in mark_referenced_resources, at resource.c:229

This occurs in stage 2 when built with -O3.  For some reason, virtual-stack-vars
doesn't get a hard register during reload.  This is a new problem introduced
in the last few days.

I have a couple of pic related patches, but the reload issue and the above
problem need to be resolved before they can be fully tested.  I did have
a complete pic build of gcc when I patched rtx_varies_p to check op0
and op1 of the lo_sum (ie, to ensure that its argument is invariant and
not just constant).  However, I decided this is wrong and that some
additional modifications need to be made to local-alloc to test for
this situation.  I think there needs to be a scan from the init_insn.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)