[llvm-commits] [llvm] r68940 - in /llvm/trunk: docs/ include/llvm/ include/llvm/CodeGen/ lib/AsmParser/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/CodeGen/ lib/CodeGen/AsmPrinter/ lib/Linker/ lib/Target/CppBackend/ lib/VMCore/ test/CodeGen/Gener

Chris Lattner clattner at apple.com
Mon Apr 13 13:12:19 PDT 2009


On Apr 13, 2009, at 12:59 PM, Eli Friedman wrote:

> On Mon, Apr 13, 2009 at 11:16 AM, Chris Lattner <clattner at apple.com>  
> wrote:
>> This could be handled by having the linker drop  
>> "available_externally"
>> symbols when it does linking, but do you expect this to be a problem
>> in practice?  Why would it be ok to inline a body in one translation
>> unit but not in another?
>
>> From the C99 rationale: "Second, the requirement that all definitions
> of an inline function be 'exactly the same' is replaced by the
> requirement that the behavior of the program should not depend on
> whether a call is implemented with a visible inline definition, or the
> external definition, of a function. This allows an inline definition
> to be specialized for its use within a particular translation unit.
> For example, the external definition of a library function might
> include some argument validation that is not needed for calls made
> from other functions in the same library."

Consider:

--- a.c
int foo();
int bar() { return foo(); }
--- b.c
inline int foo() {return 1;}
...

Do you think that it is bad to allow bar to inline the definition of  
foo from b.c?  How important is it to worry about this?  Again, it is  
straight-forward to throw the information away, but this pessimizes  
other clients (e.g. the C++ vtable example)

-Chris




More information about the llvm-commits mailing list