[LLVMdev] inlining hint

[David Vandevoorde]

On Aug 27, 2009, at 9:53 AM, Cédric Venet wrote:

> David Vandevoorde a écrit :
>> On Aug 27, 2009, at 3:07 AM, Cédric Venet wrote:
>>
>>
>>> David Vandevoorde a écrit :
>>>
>>>> I don't think those are _good_ reasons though: If one doesn't want
>>>> a C+ + function to be inlined, one shouldn't define it inline.
>>>>
>>>>
>>>>
>>> You must not have written a lot of C++ template then.
>>>
>>
>> (Ha!)
>>
>
> :) ok, your name didn't register at first, but I have read (part of)
> your book. sorry for the tone of my reply which was not very friendly
> (It happen often to me with mail, but this is not an excuse). I just
> didn't and still don't understand how you do it, but this is probably
> not the good place to discuses this.
> please accept my sincere apologies.


Apology happily accepted -- no hard feelings!


[...]
>> I don't think that how standard library or STL headers _are_ written
>> determines how they _should be_ written.
>>
>> (Templates don't force us to write excessive inline functions: Leave
>> off the inline keyword and write a member function outside the class
>> template definition, and it's no longer an inline function.)
>>
>
> What about multiple translation unit then? because from my
> understanding, this will generate multiple definition of symbol, so  
> you
> will never be able to link it (except with some strange link
> specification (weak or something like this) which seem less portable
> than declaring the function inline).


The most common practice nowadays is indeed "some strange link  
specification": Linkable template instances are placed in comdat  
sections, and the linker (or loader) ignores duplicate sections.   
That's a theoretically lousy solution (e.g., different instances might  
have been compiled differently), but in practice I haven't seen many  
problems or complaints.  (Note that all this is transparently handled  
by the compiler.)

(Comdat sections are also useful for other C++ compilation artifacts,  
such as spilled inline functions, and certain virtual function tables  
and typeinfo data structures.)

There are other ways to deal with the issue.  Our (EDG) product comes  
with a "prelinker" that assigns instances to a particular object file  
(rerunning the compiler to generate instances): In practice I find it  
not as efficient as the comdat approach, but those customers that  
cannot have linker support have a way forward with it.  Sun also had a  
neat alternative solution to the issue using an instance database of  
sorts, but it doesn't work well will traditional build systems and  
they ended up switching to a comdat-like scheme as well.  See section  
10.4 in "C++ Templates -- The complete guide".



> From the standard:
>
>    Every program shall contain exactly one definition of every
> non-inline function or object that is used in that
>    program; no diagnostic required. The definition can appear
> explicitly in the program, it can be found in the
>    standard or a user-defined library, or (when appropriate) it is
> implicitly defined (see 12.1, 12.4 and 12.8).
>    An inline function shall be defined in every translation unit in
> which it is used.



Those are requirements on source code (essentially); not on  
implementation.  (Note also: function != function template.)

	Daveed