On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
Nick Kledzik <[EMAIL PROTECTED]> writes:
I don't claim our current implementation is bug free, but the lto
interface
matches the Apple linker internal model, so we don't expect and have
not encountered any problems mixing mach-o and llvm bitcode files.
Hmmm, OK, how about this example:
a.o: contains LTO information, refers to S
b.o: no LTO information, defines S
c.o: contains LTO information, defines S at version V, S/V is not
hidden
In the absence of b.o, the reference to S in a.o will be resolved
against the definition of S in c.o. In the presence of b.o, the
reference to S in a.o will be resolved against the definition of S in
b.o.
I suppose we could refuse to inline versioned symbols, but that
doesn't seem desirable since it is normally fine.
As Chris mentioned earlier today, the Apple tool chain does not
support versioned symbols.
But if versioned symbols are a naming convention (that is everything
is encoded in
the symbol name), then this would work the same as your previous
example. Namely,
the linker would coalesce away S in c.o, which in turns tell the LTO
engine that it
can't inline/optimize away c.o's S and after LTO is done, the linker
throws away
the LTO generated S and uses b.o's S instead.
-Nick
On Jun 4, 2008, at 9:29 AM, Chris Lattner wrote:
When I look at the LLVM interface as described on that web page, I
see
these issues, all fixable:
* No support for symbol versioning.
Very true. I think it would great to work from a common model that
can be extended to support both compilers. Having a unified
interface would be very useful, and we are happy to evolve the
interface to suit more general needs.
