[llvm-commits] pr11367

[Chris Lattner]

MHO is that mainline is behaving correctly.  We don't want LTO or llvm-link to keep all bitcode files around in memory to support a theoretical use case.

-Chris

On Nov 14, 2011, at 10:21 AM, Tanya Lattner wrote:

> 
> 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
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits