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

[Jeffrey A Law]

  In message < 99060723223102.01171@ns1102.munich.netsurf.de >you write:
  > Yes, but this one could eventually be solved by tweaking
  > PREFERRED_RELOAD_CLASS as Jeff suggested long ago.
Must have been long ago, because I do not remember it.

  > >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.
  > 
  > Hmm, I thought the code in finalize_pic() takes care of that? It places
  > init_v4_pic as the first insn. Do you have a testcase where later
  > optimization passes put pic-referencing insns before that? Hmm, eventually
  >  finalize_pic should emit some kind of barrier after init_v4_pic.
Is there an obvious (to a compiler) dependency between the code that sets up
your PIC register and insns which use the PIC register?  If not, then the
second scheduling pass could rearrange the code and you would lose.

By obvious dependency I mean does the code to set up the PIC register have
a set of a reg that is later referenced by insns which use the PIC register.
ie, is the PIC register explicitly mentioned in the RTL or is it hidden?


  > >> 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 so
  > me
  > >> 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:
Like Richard, I don't see that your approach is any significant advantage over
fixing a register for PIC usage.

  > Hmm, thinking about it, my approach could be better implemented in
  > the backend if there was a FINALIZE_PIC_2 running somewhere after
  > flow/combine
  > and before reload. Then we would move pic_offset_table_rtx REG_DEAD notes
  > to the last REG_EQUIV containing it (or should a new init_v4_pic be
  > emitted then?).
  > And pic_offset_table_rtx could forcibly be initialized if any REG_EQUAL
  > note contains a CONST_DOUBLE. This would be a self-contained patch solely
  >  in the backend (ok, FINALIZE_PIC_2 would have to be inserted into
  >  toplev.c), giving us most advantages of pic_offset_table_rtx being a
  >  pseudo, or?
This is terribly gross.

My recommendation.  Fix the PIC register.  We're focusing way too much on the
optimization aspects of this issue.  Yes, we lose a register.  Big deal, it's
not like the PPC is that terribly register poor.  Other ports do this and not
a sole has ever complained about PIC efficiency on those ports.  Also keep in
mind that you pay this price in library code only.  Most programs are not
performance bound by a library -- if they were, they should be statically
linked).

One day we may have the ability to safely perform lazy allocation of PIC
registers and when we do, we can convert the PPC (and other) ports to us that
scheme.

jeff