Re: [PCH] constant pools rewrite

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Mon, 18 Feb 2002 16:19:47 -0800
> From: Richard Henderson <rth@redhat.com>
> Cc: gcc-patches@gcc.gnu.org
> Mail-Followup-To: Richard Henderson <rth@redhat.com>,
> 	Geoffrey Keating <geoffk@cygnus.com>, gcc-patches@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5.1i
> 
> On Mon, Feb 18, 2002 at 09:09:57AM -0800, Geoffrey Keating wrote:
> > Some future work, which I don't have time for right now but which
> > might be interesting for someone in the future:
> 
> Given that you poked at this at all, I think it is a mistake
> that you didn't simply rip out all of the rtx_const nonsense.
> This is left over from when we had per-function obstacks, and
> should be irrelevant with GC.

You know, now that I look at it, you're right; it should all go.
(At least I removed the much more horrible stuff for trees.)

> > - Work out why the RTX constant pool is per-function, when the tree
> >   constant pool is per-file.  If (as I suspect) there's no real
> >   reason, make the RTX constant pool per-file.  Delete the code in the
> >   rs6000 backend that creates its own per-file RTX constant pool.
> 
> Because some ports ...
> 
> > - Work out why the ARM backend has its own constant pool handling, and
> >   merge that functionality back into the middle-end.  I'm sure lots of
> >   ports could benefit from it.
> 
> ... require constant pools *within* the function, so that 
> they can address them with 8-bit pc-relative relocs.
> 
> See arm, mcore, sh, s390 to name a few.

I am enlightened.

> But for everyone else, we should indeed be using per-file pools.

Well, something for future work.  I think a bit more design would be
helpful here, there's a bunch of things that would be nice to do with
constant pools that we don't do (or do only for some port but not in
all the places where it would be helpful).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>