[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

[Eli Friedman]

On Mon, Apr 13, 2009 at 1:12 PM, Chris Lattner <clattner at apple.com> wrote:
> 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?

It can lead to wrong code generation.  The importance is hard to judge.

> Again, it is
> straight-forward to throw the information away, but this pessimizes
> other clients (e.g. the C++ vtable example)

C99 semantics minimally require something like the following for an
inline function: If only one of the files provides a declaration or
definition of the given symbol, we can keep it.  If two files provide
identical definitions with available_externally, we can keep either
one.  Otherwise, we must discard both.

I think this scheme addresses the C++ vtable example.  Otherwise, we
can always add available_externally_odr :)

Of course, we could implement C99 inline purely in the front-end: we
just emit the inline version as an internal function with a different
name, and make direct calls use that instead of the external version.

-Eli