[llvm-commits] pr11367

[Tanya Lattner]

On Nov 14, 2011, at 8:55 AM, Rafael Espíndola wrote:

> I was thinking a bit about pr11367. The most direct way to solve it is
> keeping the list open until the linker is done adding files, but maybe
> there is a better way.
> 
> What was the intended use case of lazy linking? Speeding up LTO?

I implemented lazy linking for an outside project where I want to link with a bc library and only link in the functions that are used.  We use the LinkModules() API directly. I talked to Chris about this and he wanted LTO to take advantage of this as well, so it seemed like a win for both.

> If
> so, it might be better to drop these function at the end of
> -std-compile-opts and change back the linker to keeping everything.
> The advantages would be

I really don't want to run the optimizer on everything when the linker can easily do this.

> 
> * llvm-link is again just a IL version of cat

I'm sure this can be up for debate as what llvm-link is really supposed to do. I don't want to remove this functionality from the API. If its decided that llvm-link is really catting IR files together, then its better to make an option to turn it off (for llvm-link if it chooses) and have it on by default.

-Tanya

> * LTO is even faster, as we avoid writing to disk the functions that
> we currently drop when reading in.
> 
> It is true that we would drop more available_externally functions.
> Right now if we drop them or not depends on the file order.
> 
> Both the current solution and the dropping them in -std-compile-opts
> could also introduce a regression compared to the old way where an
> available_externally function in one file would be available for use
> in any other file. I don't think this would be a problem in practise.
> Any translation unit that uses an inline function is likely to see its
> definition.
> 
> Cheers,
> Rafael