[llvm-commits] pr11367

[Matt Pharr]

It's not a completely theoretical use case: the ispc compiler depended on the old behavior from LinkModules() ("link everything in the provided modules together, and don't be clever about skipping stuff that seems to not be used"), and the lazy linking change broke that.

I've since worked around this API change with a somewhat ugly hack, but it seems to me that the basic functionality of having the ability to easily cat modules together is worth having around.  I don't have an opinion about what llvm-link should do, but I do believe that the APIs should still provide this functionality somehow.  (One possibility being the patch I sent to llvm-dev a week or so ago.)

Thanks,
-matt

On Nov 14, 2011, at 10:40 AM, Chris Lattner wrote:

> 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
>