This is the mail archive of the
mailing list for the GCC project.
Re: Fix powerpc-linux gcc.dg/20020103-1.c
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
> >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.
IBM OzLabs - Linux Technology Centre