Re: [PATCH] -fpic problems on PPC, a different approach

[Geoff Keating <geoffk at ozemail dot com dot au>]

> From: Franz Sirl <Franz.Sirl@munich.netsurf.de>
> Date: Sun, 6 Jun 1999 21:12:37 +0200
> Cc: <geoffk@ozemail.com.au>

> 1. reload may generate new uses of pic_offset_table_rtx, which may result in
> miscompilation (gcc.dg/980523-1.c)
> 2. some kind of code typical for glibc math routines and it's headers may end up
> in trying to setup pic_offset_table_rtx during reload, which then aborts. A

Really, these are the same problem.  The problem is that reload
generates new uses of pic_offset_table_rtx after register allocation.
Sometimes, it happens that the routine never used pic_offset_table_rtx
before, which causes different and more visible problems, but it's the
same underlying problem.

> After thinking about what's going wrong in reload, I saw another
> possibility.  Don't look at pic_offset_table_rtx as a regular
> pseudo, look at it more like a frame_pointer_rtx, which stays alive
> during the whole function. The only difference being that
> pic_offset_table_rtx may not at all show up, depending on the
> code. Now the only important thing to do is to avoid attaching
> REG_DEAD notes to any uses of pic_offset_table_rtx. So I introduced
> a new macro PSEUDO_REGNO_EVER_LIVE and used it in
> flow.c/mark_regs_used() and voila, bug#1 was fixed (at least the
> testcase).

Your patch concentrates on making sure that the PIC register
never goes dead.  However, you may also need to do something to make
sure that gcc never moves the initial setting of the PIC register to a
place in the code after it might be used---in practise, this means
that the PIC register code must stay at the top of the routine.

> So, now I would like to know a few things:
> - is this a valid approach and might it be accepted for gcc?
> - I'm not exactly sure about the placement of PSEUDO_REGNO_EVER_LIVE in flow.c
> - do I have to handle this in combine.c too? Or in other files/places?
> 
> This still leaves us with problem #2, but this might be solvable with some
> tweaking of PREFERRED_RELOAD_CLASS and maybe SECONDARY_RELOAD_CLASS?

If you're going to do this, you might as well allocate a fixed hard
register for the PIC register.  This is how some of the other ports
used to do it, and it avoids all these problems.  Unfortunately, it
comes at a significant efficiency cost:

- The register cannot be re-used for anything else while the routine
  is running.  This is a similar effect to your setting of
  PSEUDO_REGNO_EVER_LIVE, and is what fixes problem #1.

- The register cannot even be used for anything else if the routine
  accesses _no_ globals.  This is why the solution fixes problem #2.

Now, if this was what we had to do to make it work, then we'd just
have to pay the efficiency cost and try to look happy about it.  But I
think that even my patch (which is pretty horrible) has less of an
efficiency cost than this, because the cases that it affects are
rare.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>