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

["Zack Weinberg" <zack at codesourcery dot com>]

Per Bothner <per@bothner.com> writes:

>> Entirely serious question: why is the rest of init_regs in category 2?
>> *Should* it be in category 2, or is this an implementation accident?

> Perfectly reasonable question, and I don't really know.  This gets
> into back-end organization, which I'm not as familiar with.  So I
> did an initial conservative change which was the minimal needed for
> the compile server.

That's understandable, but I would be more comfortable with the change
if you did the investigation to find out what exactly is going on here.

> A related issue:  Should we use the "_once" suffix for initialization
> that shold only happen once, even given an compile server with multiple
> input files and multiple output files?  In my existing patch, I split
> up front-end initialization into two similar but different categories:
> (1a) true one-time-only front-end initialization; and
> (2a) (re-)initialization per *input* file.
> (Note these are different if we allow multiple input files per output
> file, as with Geoff's inter-module optimizations.)
>
> I've been calling (1a) xxx_initially and (2a) xxx_init.  Perhaps we
> should use the convention (1a) xxx_init_once and (2a) xxx_init.

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.)

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.  So I like patches that move work to
category (1a).  But they need to be backed up with investigation to
prove they're safe.

zw