Re: [PATCH] Inline even functions containing static variables (was Re: Removing space waste for g++ static inlined objects)

[Jason Merrill <jason at redhat dot com>]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

> On Fri, Mar 16, 2001 at 04:53:37PM +0000, Jason Merrill wrote:

>> The mangled name of the guard is derived from the mangled name of the
>> variable being guarded.  As long as the variables don't clash, neither
>> should the guards.

> The thing is that we don't mangle static local variables unless they are
> externally visible (use var.number instead), but use the new ABI mangling
> for guard variables. If we used the new ABI mangling for all local
> variables, then this push_local_name call would not be necessary.

Either we should use the ABI mangling for both, or neither.  I don't much
care which.

Or we could actually derive the mangled name of the guard from the mangled
name of the variable, rather than from what we expect the mangled name of
the variable to be.

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

> The latter is true -- but it's not necessary to mangle names during
> processing of the inline function.  Only if, and when, it is ever
> output (possibly inlined into something else).

OK, that makes sense.  We currently mangle everything at declaration time,
but I'd be open to changing that.

Delaying some parts of mangling would be quite useful for precompiling a
header which uses the anonymous namespace....

> Therefore, I believe the discriminators (or, preferably, the information
> needed to compute them) should be present in the tree structure.

OK.

> However, it seems likely that the BLOCK tree can/should/does contain
> this information, so maybe we can use that instead.

True, though reconstructing that information from the BLOCK sounds a bit
complex.  It would seem simpler just to record the sequence number in
the decl itself.

> Finally (reiterating a point that I tried, unsuccessfully, to make at
> the ABI committee), I believe it was a mistake to specify a mangling
> for these local entities.  It is true that the standard requires
> shared copies of these variables -- but it is, in practice, almost
> impossible to come up with a scheme that more than one compiler can
> implement efficiently and correctly.

I still think you're overstating the complexity.  How is it so difficult to
deal with lexical order efficiently and correctly?  Usually we parse the
function in lexical order.  :)

> I still believe a better design decision would have been to say that the
> ABI required compilers not to inline functions that had multiple entities
> with the same name -- that's one that people could have gotten right, and
> with almost no impact on real user code.

I suppose that wouldn't have been so bad, but it seems easy enough to me
just to DTRT.

And then there's the bug that Ron was trying to fix with the patch that
started this thread: even though we were discarding duplicate functions, we
still had duplicate static data associated with the functions.  The fix is
to make the static data comdat as well.

Jason