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

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:

    Jason> Too soon for what?  The list of local names should only be
    Jason> used in generating the mangled names of local variables,
    Jason> which happens when their declarations are seen.  Inlining
    Jason> must not have any effect on those names.

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

In my opinion, mangling should be a very separable process.  

If mangling things correctly requires knowledge of the current
context, that is a bad thing.

One advantage to this approach (besides the obvious software
engineering cleanliness) is that you can easily swap out the mangler.

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

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

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.  Each of the 4 C++ compilers I
have worked on will need some additional infrastructure to get this
right, and each is sufficiently complex that the likelihood of obscure
bugs is very high.  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.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com