Lazy allocation of DECL_ASSEMBLER_NAME

[Jan Hubicka]

> 
> Jan --
> 
> I believe that your cgraph stuff has caused us to be much less lazy
> about allocating DECL_ASSEMBLER_NAME than we used to be.  
> 
> A while back, I changed DECL_ASSEMBLER_NAME to allocate lazily because
> I observed that we were allocating a ton of space for mangled names
> for entities that were never omitted.  Now, it looks like cgraph has
> gone back to using DECL_ASSEMBLER_NAME unconditionally.
> 
> It is basically a bug for any part of the code in the compiler to use
> DECL_ASSEMBLER_NAME other than the routines that actually emity
> assembly code.  It should be possible to assign DECL_ASSEMBLER_NAMEs
> only after the entire translation unit has been parsed, analyzed, and
> it has been decided what functions and variables need to be omitted to
> the object file.  All other uses are either wrong, or hacks that
> should be replaced with a cleaner mechanism.
> 
> To check for whether two declarations are the same, just compare their
> addresses.  If a front end creates two FUNCTION_DECLs or VAR_DECLs
> that happen to have the same DECL_ASSEMBLER_NAME that's either a bug
> or an intentional trick on the part of the front end: by the time
> things get to the middle end there should be only one DECL for each
> declared entity.
> 
> Would you please see if you can fix this problem -- after fixing some
> of the wrong-code/ICE problems in 3.4?

I will try to look into it, but last time I tried to do so, both C and
C++ frontends was creating separate declarations for local declarations,
forward declarations and such, so single function got many DECLs.
Also we can't hash directly the addresses as the hashtable is saved into
PCH headers, so I am unsure about better sollution to the hashing.
I need at least one entity that is stable across PCH and multiple
declarations...

Honza
> 
> Thanks,
> 
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
> 
>