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

[Devang Patel <dpatel at apple dot com>]

On Jun 4, 2008, at 6:09 PM, Nick Kledzik wrote:

> On Jun 4, 2008, at 5:39 PM, Ian Lance Taylor wrote:
> > Nick Kledzik <kledzik@apple.com> writes:
> >
> > > 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.
> >
> > Versioned symbols are not a naming convention, but they aren't all
> > that different from one.  Basically every symbol may have an optional
> > version, and when a symbol has a version the version may be hidden or
> > not.  A symbol definition with a hidden version may only be matched  
> > by
> > a symbol reference with that exact version.  A symbol definition with
> > a non-hidden version definition may be matched by a symbol reference
> > with the same name without a version.  This is most interesting in  
> > the
> > dynamic linker, of course.
> >
> > How does the linker inform the plugin that the plugin is not  
> > permitted
> > to use c.o's S?
> In the previous case where S was weak, the call to  
> lto_codegen_add_must_preserve_symbol("S")
> caused the LTO engine to know it could not inline S (because it was
> a weak definition and used outside the LTO usage sphere).

weak definition is the deciding factor. Optimizer can inline a  
function at the call site irrespective of whether it is used outside  
LTO usage sphere or not. The outside the LTO sphere use determines  
whether to preserve the function body, when the function is inlined  
everywhere inside LTO usage sphere,  or not.

> And then
> after LTO was done, the linker threw away the LTO produced S and used
> the one from c.o instead.
>
> In this case S is a regular symbol.  So the previous trick won't  
> work.  Probably
> the best solution would be to add a new  lto_ API to tell the LTO  
> engine to
> ignore a definition is already has.  It would make more sense to use  
> this
> new API in the weak case too.

If the optimizer can handle the symbol versioning case when one  
definition with version is defined in the same source file as the  
reference then you don't need new API.

For example,

a.o : refers to S and defines S at version V.
b.o : defines S.

Is inliner, at compile time allowed to inline uses of S in a.o using  
the definition it has ?

-
Devang