[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