Re: Fix powerpc-linux gcc.dg/20020103-1.c

[Alan Modra <amodra at bigpond dot net dot au>]

On Mon, Nov 29, 2004 at 11:42:15AM -0800, Geoff Keating wrote:
> On 29/11/2004, at 11:37 AM, Geoff Keating wrote:
> >On 25/11/2004, at 9:32 PM, Alan Modra wrote:
> >
> >>On Wed, Nov 10, 2004 at 12:58:25PM +1030, Alan Modra wrote:
> >>>On Mon, Nov 08, 2004 at 10:01:33PM +1030, Alan Modra wrote:
> >>>>This fixes 20020103-1.c with a minimal change.
> >>>
> >>>The same for gcc-3.4.
> >>
> >>Ping!  http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00583.html
> >>and http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00789.html
> >
> >In my previous mail, I said:
> >
> >>I don't think this patch is the right direction.  You're working
> >>around reload in the backend.  Instead, you should teach reload how to
> >>load from a SYMBOL_REF.  I believe this is just a change to
> >>rs6000_emit_move.
> >
> >Why didn't you do that?

But I did!  I wrote two patches.  The first one delayed creating the
unspec rtl.  The second one, referenced in the URL above, changes
rs6000_emit_move to load from the SYMBOL_REF during reload.  You'll see
that it moves the gen_movsi_got code before a reload_in_progess test
that would otherwise cause rs6000_emit_move to leave the SYMBOL_REF as
a set, and it tweaks TARGET_CANNOT_FORCE_CONST_MEM to stop reload
putting the SYMBOL_REF into the constant pool.

> Oh, I see, you said:
> 
> >> I don't think this patch is the right direction.  You're working
> >> around reload in the backend.
> >
> >Not really.  I'm delaying generation of unspec rtl that generic code
> >can't handle.  Surely that is a good thing, as it fits in with the
> >philosophy of keeping target dependent wrinkles out of intermediate
> >representations as long as possible.  As demonstrated by the fact that
> >this change allows us to generate ideal code without further
> >complicating reload with target dependent information.
> 
> No, there's a right time to introduce target dependencies, and the 
> right time for a load operation is before sched1.
> 
> >Of course, that argument fails if you really need the unspec early.
> >I'm reasonably confident we don't.  As far as I can tell,
> >unspec_movsi_got was a half-baked attempt to reserve r30 early
> >enough so that r30 was free to use if a function didn't make any got
> >accesses.  True?
> 
> Yes; but why can't we do that?

I explained that before.  reload might force constants to memory, for
which accesses require use of r30.  So we don't know whether r30 is
really free until after reload.

> >>  Instead, you should teach reload how to
> >> load from a SYMBOL_REF.  I believe this is just a change to
> >> rs6000_emit_move.
> >
> >I looked at changing reload before taking the approach I did.  It's not
> >quite as simple as you indicate, ie. more than just rs6000_emit_move
> >needs changing, I think.
> 
> Can you go into more details?

Already explained too.

> Note that the patch you presented in the URLs above doesn't delay 
> generation of anything, and in fact goes exactly against the direction 
> you said was a good thing.

Yes, it does it the way you wanted.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre