This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rs6000 toc reference rtl again

On Tue, Apr 03, 2012 at 07:49:04PM +0100, Richard Sandiford wrote:
> Alan Modra <> writes:
> > Now that we are back in stage1, I'd like to apply
> >, 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, won't it?

Alan Modra
Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]