Placement of vtables, inlines and such

[Christophe de Dinechin]

From: dehnert at baalbek.engr.sgi.com (Jim Dehnert)

> Another observation regarding the heuristic vs. COMDAT choice...
> Modulo not knowing what the heuristics in question are, it seems to me 
> that, if the ABI specifies COMDAT processing it will always work with 
> nothing further, and if it's safe an implementation could still elide 
> (some of) the unnecessary copies (which probably requires ABI
> identification of the required copy), but wouldn't need to.
>
> Also, along with the COMDAT choice, we would also want to make sure 
> there was a mechanism available to also eliminate duplicate copies of 
> associated information like debug sections.

First, the "usual" heuristic (which is usual because it dates back  
to Cfront) is to emit vtables in the translation unit that contains  
the definition of the first non inline, non pure virtual function.  
That is, for:

	struct X {
		void a();
		virtual void f() { return; }
		virtual void g() = 0;
		virtual void h();
		virtual void i();
	};

the vtable is emitted only in the TU that contains the definition of h().

This breaks and becomes non-portable if:
- There is no such thing. In that case, you generally emit duplicate  
versions of vtables
- There is a "change of mind", such as having the above class followed by:

	inline void X::h() { f(); }



Now, the COMDAT issue is as follows: a COMDAT section is, in some  
cases, slightly more difficult to handle (at least, that's the  
impression Jason gave me). For statics with runtime initialization,  
what you can do is reserve COMMON space ('easier'), then initialize  
that space at runtime. As I said, the problem is if two compilers  
disagree on whether this is a runtime or a compile time  
initialization, such as in :

	inline int f() { return 1; }
	int x = f();			// Static (COMDAT) or  
Dynamic (COMMON) initialization?

So I personally recommend that we put everything in COMDAT.

Regards
Christophe