Re: PATCH: call move init_reg_modes call (for compile-server)

[Per Bothner <per at bothner dot com>]

[This is a re-post.  For some weird reason sources.redhat.com alias
gcc.gnu.org decided the following looked like spam.  I didn't get
through automatically as a subscriber because I use a separate
mailbox for the gcc mailing lists.  I also fixed the embarassing
typo in the Subject line.]

Zack Weinberg wrote:

> My understanding is that when there's an init_xxx_once and an
> init_xxx, the latter is per *function*.  In the name of transparency,
> I would suggest init_xxx for (1a) only, init_xxx_eachtu for (2a), and
> init_xxx_eachfn for per-function initialization.  (tu is for
> translation unit.)

How about:

init_xxx_once
   - global run-once initialization
init_xxx_eachsrc (instead of init_xxx_eachtu)
   - (re)init for each source module (translation unit)
init_xxx_eachasm
   - (re-)init for each output (asm) file
init_xxx_eachfn
   - (re-)init for each function
plain init_xxx
   - should be avoided and renamed to one of the above

I'm not volunteering to change all of these, but it would be
helpful to have a convention we can follow and work towards.

> Now call me a crazy dreamer, but I think the goal to work towards here
> is not to have to do any work in category (2a); reinitializing for a
> new input file should be just a matter of throwing away the data
> structures allocated for the previous file, with the global
> infrastructure still intact.

I agree.  The compile-server has relatively little in category (2a)
(the _eachsrc category), but we do have to go through the symbol
table and clear out bindings, and then restore the builtins, for
example.  A data structure that could avoid that wold be fine - but
not that we want to use the same INDENTIFIER nodes, but clear out
the bindings - which are essentially caches.

Mike Stump has been experiementing with a different model, where
all the old bindings are remembered, but we use "timestamps" to
determine which bindings are currently active.  That is an
attractive approach.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/