Re: rs6000 toc reference rtl again

[Alan Modra <amodra at gmail dot com>]

On Tue, Apr 03, 2012 at 07:49:04PM +0100, Richard Sandiford wrote:
> Alan Modra <amodra@gmail.com> writes:
> > Now that we are back in stage1, I'd like to apply
> > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
> > toc reference rtl in order to properly specify r2 dependencies.  More
> > commentary in that url.  I'm reposting the patch here since the old
> > one no longer applies cleanly, and I've added some ENABLE_CHECKING
> > code in rs6000_delegitimize_address.
> 
> Sorry to be a pain, but I don't think HIGH is supposed contain
> regs either.  Both HIGH and CONST are supposed to be true constants.

Eh, so the existing use of CONST is wrong then.  ;-)

I'm proposing
  (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL)
for the small model, and
  (high (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL)))
  (lo_sum (reg hi) (unspec [(symbol_ref sym) (reg r2)] UNSPEC_TOCREL))
for medium/large model.

You can see why I'd like to keep it this way;  The medium/large rtl is
a natural split of the small rtl.  (I'm going to experiment with
splitting the small rtl after reload for medium/large to see whether
that helps our usage of call-saved regs in loops.)

I'm not wedded to the representation, *but* we do want gcc to treat
the high part as a constant.  That's important because we don't ever
want reload saving the high part to a stack slot!  Which is what does
happen if you don't somehow tell gcc it is a constant.

Besides, the high part *is* a constant within any given function.  So
is the low part for that matter.  The only reason I want r2 mentioned
in this rtl is for register liveness, eg. so that a load of a function
pointer (which loads r2) for an indirect call doesn't get scheduled
before any uses of the old r2.

The alternative of removing r2 from the unspec and attaching a
(use (reg r2)) to all instructions that have this addressing form
might be clean but will require major duplication of patterns in
rs6000.md, won't it?

-- 
Alan Modra
Australia Development Lab, IBM