Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names

["Diego Novillo" <dnovillo at google dot com>]

[ Moved to gcc@gcc.gnu.org ]

On Fri, Aug 1, 2008 at 03:33, Bill Maddox <maddox@google.com> wrote:

> I am continuing to make progress with the LTO streamer on C++ code,
> and finding a considerable amount  of front-end specific crud hanging
> off of the GIMPLE, particularly related to templates.  This is not
> surprising given the current strategy for generating debug information
> (late, in the back-end).   The LTO IR must be language-independent,
> hower, and the current short-term plan of record, as I understand it,
> is to strip out left-over front-end specific parts of the tree in
> tree.c:free_lang_specifics, accepting that this will break debug info
> generation until a satisfactory alternative is devised.

Yes.  That coupled with early debug info emission in the FE.

>
> Finding that DECL_CONTEXT might include portions of what looked like
> template definitions, and surmising that  lexical nesting was a
> language artifact that should no longer be of significance beyond the
> front-end, I attempted to clear DECL_CONTEXT in free_lang_specifics.
> This resulted in an assertion failure in
> cp/mangle.c:write_unscoped_name.  It appears that the name mangling
> code, as one would expect, is very interested in such nesting, and
> examines DECL_CONTEXT in multiple locations.  None of this would be of
> any consequence if the name mangling were complete upon entry to the
> middle-end, but it can in fact be invoked via a langhook from
> DECL_ASSEMBLER_NAME.  Setting the assembler name is performed lazily
> in the back-end, requiring nesting relationships reflected in
> DECL_CONTEXT to be preserved to this point.
>
> My assertion is that the langhook must go, and that mangled names
> should be generated before invoking the middle-end.  Given the baroque
> treatment of the assembler name, however, I don't think it will be
> sufficient simply to make a pass over the declarations in
> free_lang_specifics setting the assembler name.
>
> Any advice from someone who deeply understands this stuff?

I can't claim any kind of knowledge of the C++ FE, but from the
point of view of the middle end, I would prefer if all the names
are decided right before, or during gimplification.

FE folks, any reason why we couldn't set assembler name as the FE
hands off the function to the gimplifier?  In principle,
free_lang_specifics would be a good place for it, I think.


Diego.