[llvm-dev] LTO on libraries

[Mehdi Amini via llvm-dev]

> On Dec 4, 2015, at 4:51 PM, David Callahan <dcallahan at fb.com> wrote:
> 
> Thanks
> 
> I had two small learnings. 
> 1. Don’t name the output of llvm-link as a “.o” (the subsequent clang ignores it) 
> 2. You need to have optimization flags like –O3 on the second clang, the on on the first is dropped.
> But this did as I had hoped:
> 
> bin/clang -flto -O3 -c {a,b,c}.o
> bin/llvm-link -o abc.bc {a,b,c}.o
> bin/clang -O3 -o abc.o -c abc.bc
> bin/clang -o test main.c abc.o

Note that you may want to disable the optimization on the first run of clang:

bin/clang -flto -O3 -c {a,b,c}.o -mllvm -disable-llvm-optzns

— 
Mehdi


> 
> From: <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> on behalf of Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>>
> Date: Friday, December 4, 2015 at 4:27 PM
> To: David Callahan <dcallahan at fb.com <mailto:dcallahan at fb.com>>
> Cc: LLVM Dev Mailing list <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> Subject: Re: [llvm-dev] LTO on libraries
> 
> 
>> On Dec 4, 2015, at 4:12 PM, David Callahan <dcallahan at fb.com <mailto:dcallahan at fb.com>> wrote:
>> 
>> Thanks for the response.
>> To clarify in your suggestion, llvm-link will combine the modules but not run the optimization pass, that is still delayed until the final binary is built, correct?
> 
> Yes.
> You can use clang to generate a .o (as a real binary), that you can then wrap in an archive library.
> 
> 
>> 
>> My use case is apply LTO to roughly program subsets; sacrificing effectiveness to avoid scaling problems and to allow the artifacts to be reused like archives and cached like .o’s.
> 
> You’re probably be interested in ThinLTO that is currently being implemented: scalability and incrementally are scheduled.
> 
>> I need to trigger the optimizer on the intermediate rather than defer to final link for these goals.
> 
> Just run clang on the output of llvm-link :)
> 
> Note: you’re not having the same linker semantic with an archive containing one .o compared to an archive with multiple .o. So you need to be careful.
> 
> — 
> Mehdi
> 
> 
>> 
>> —david
>> 
>> 
>> From: <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> on behalf of Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>>
>> Date: Friday, December 4, 2015 at 4:02 PM
>> To: David Callahan <dcallahan at fb.com <mailto:dcallahan at fb.com>>
>> Cc: LLVM Dev Mailing list <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
>> Subject: Re: [llvm-dev] LTO on libraries
>> 
>> 
>>> On Dec 4, 2015, at 3:54 PM, David Callahan via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> Hello,
>>> 
>>> Is there a combination of the current tools would would allow me to apply LTO to a set of object files where are less than an entire application? Similar to “ld –r”  for doing a partial link.
>>> I assume it would start with “clang –flto –c {a,b,c}.c” but the a subsequent link step fails  do to unresolved references of course.
>>> Using llvm-link will linke the bitcode files but does not trigger compilation.
>> 
>> You can llvm-link and then run clang.  Note that the result of LTO in this case is not as powerful as when it is linker driver, since you can’t internalize.
>> You may also want to look at llvm-lto, but it can be annoying because it requires (AFAIK) an export list.
>> 
>> What is your use-case?
>> 
>> — 
>> Mehdi
>> 
>> 
>> 
>>> 
>>> Thanks
>>> david
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMF-g&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiPUrFdOHdaobP7i4hoA&m=vTfrtiCb9BO_em6D4lOQLhfgsFmoPI-bQA7aXuKAAdA&s=OPMnWwRmxskPv9ZQVVz4U6Zkxfni3nvdAa_RkyNe8WE&e=>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151204/3a8733f6/attachment.html>