Re: [whopr] Design/implementation alternatives for the driver and WPA

[Nick Kledzik <kledzik at apple dot com>]

On Jun 4, 2008, at 5:00 PM, Ian Lance Taylor wrote:
> Nick Kledzik <kledzik@apple.com> 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.