Lazy allocation of DECL_ASSEMBLER_NAME

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

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

Hi Mark,

Could you mention this in the documentation of DECL_ASSEMBLER_NAME in
c-tree.texi?

> To check for whether two declarations are the same, just compare their
> addresses.

You mean, the addresses of the trees, or the addresses of the objects
(presumably you would use fold and see if it was integer_zero_node or not)?

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

I don't believe that the frontends actually ensure this.  For instance,

extern int x;
extern int y asm ("x");

will produce two DECLs that refer to the same integer.

Likewise, I believe with Zack's c-decl changes, I believe that it
always returns the new DECL, which means that in code like:

extern int foo();
int bar(void) { return foo(1); }
extern int foo(int);
int baz(void) { return foo(2); }

bar will reference one DECL of foo, and baz will reference a different
one.  I think there are cases (perhaps even this example) where it'll
do this even without Zack's changes.

-- 
- Geoffrey Keating <geoffk@geoffk.org>