Nick Lewycky wrote:> Sanjiv.Gupta at microchip.com wrote: >> >> >> A common followup question is "but how do I link native libraries into >> my .bc file". You don't. A .bc file is llvm ir, you can't put a native >> binary library into a .bc (barring sticking it in as a string, etc). >> >> The build then looks like: >> >> a) 'llvm-gcc -c -flo -O2' to generate the .bc files. >> b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a. >> c) 'llc' to turn your combined .bc into a .s >> d) 'as' to turn your .s into a .o >> e) 'ld' to turn your .o into a .so or final executable. This is the step >> where you get to specify all the native libraries to link with. >> >> You can use 'gcc' to merge steps d and e (it just runs as and ld for >> you). Or you can use the gold plugin to merge steps b through e, but >> with the added benefit that it will optimize slightly better. See the >> llvm LTO documentation on why. >> >> [Sanjiv] - This is what PIC16 does. llvm-ld has an option called '-b' >> that you can >> use to specify the output bitcode file name. Unfortunately, llvm-ld >> always tries to >> generate a native executable (or a shell script) as well and >> currently there is no way to disable that. >> Maybe an option like '-no-native' will be come handy. > > Yes there is, it's -link-as-library. > > NickWell, -link-as-library is not quite same as a building a final executable .bc. The set of optimizations run is also different. - Sanjiv
Sanjiv Gupta wrote:> Nick Lewycky wrote: >> Sanjiv.Gupta at microchip.com wrote: >>> >>> >>> A common followup question is "but how do I link native libraries into >>> my .bc file". You don't. A .bc file is llvm ir, you can't put a native >>> binary library into a .bc (barring sticking it in as a string, etc). >>> >>> The build then looks like: >>> >>> a) 'llvm-gcc -c -flo -O2' to generate the .bc files. >>> b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a .a. >>> c) 'llc' to turn your combined .bc into a .s >>> d) 'as' to turn your .s into a .o >>> e) 'ld' to turn your .o into a .so or final executable. This is the step >>> where you get to specify all the native libraries to link with. >>> >>> You can use 'gcc' to merge steps d and e (it just runs as and ld for >>> you). Or you can use the gold plugin to merge steps b through e, but >>> with the added benefit that it will optimize slightly better. See the >>> llvm LTO documentation on why. >>> >>> [Sanjiv] - This is what PIC16 does. llvm-ld has an option called '-b' >>> that you can >>> use to specify the output bitcode file name. Unfortunately, llvm-ld >>> always tries to >>> generate a native executable (or a shell script) as well and >>> currently there is no way to disable that. >>> Maybe an option like '-no-native' will be come handy. >> >> Yes there is, it's -link-as-library. >> >> Nick > Well, -link-as-library is not quite same as a building a final > executable .bc..bc files aren't executable so I'm not entirely sure what you mean. 'llvm-ld -link-as-library' takes a group of .bc files and merges them before running the link-time optimizations over them, then emits the result as a .bc file.> The set of optimizations run is also different.How so? Checking llvm-ld's source, the only possible difference I can see is that passing -link-as-library will cause llvm-ld to ignore the -post-link-opts flag which almost certainly doesn't matter because you were almost certainly not using it. Nick
Nick Lewycky wrote:> Sanjiv Gupta wrote: >> Nick Lewycky wrote: >>> Sanjiv.Gupta at microchip.com wrote: >>>> >>>> >>>> A common followup question is "but how do I link native libraries into >>>> my .bc file". You don't. A .bc file is llvm ir, you can't put a native >>>> binary library into a .bc (barring sticking it in as a string, etc). >>>> >>>> The build then looks like: >>>> >>>> a) 'llvm-gcc -c -flo -O2' to generate the .bc files. >>>> b) 'llvm-ld' to combine them into a single .bc. No, not a .so nor a >>>> .a. >>>> c) 'llc' to turn your combined .bc into a .s >>>> d) 'as' to turn your .s into a .o >>>> e) 'ld' to turn your .o into a .so or final executable. This is the >>>> step >>>> where you get to specify all the native libraries to link with. >>>> >>>> You can use 'gcc' to merge steps d and e (it just runs as and ld for >>>> you). Or you can use the gold plugin to merge steps b through e, but >>>> with the added benefit that it will optimize slightly better. See the >>>> llvm LTO documentation on why. >>>> >>>> [Sanjiv] - This is what PIC16 does. llvm-ld has an option called >>>> '-b' that you can >>>> use to specify the output bitcode file name. Unfortunately, llvm-ld >>>> always tries to >>>> generate a native executable (or a shell script) as well and >>>> currently there is no way to disable that. >>>> Maybe an option like '-no-native' will be come handy. >>> >>> Yes there is, it's -link-as-library. >>> >>> Nick >> Well, -link-as-library is not quite same as a building a final >> executable .bc. > > .bc files aren't executable so I'm not entirely sure what you mean. > 'llvm-ld -link-as-library' takes a group of .bc files and merges them > before running the link-time optimizations over them, then emits the > result as a .bc file. > >> The set of optimizations run is also different. > > How so? > > Checking llvm-ld's source, the only possible difference I can see is > that passing -link-as-library will cause llvm-ld to ignore the > -post-link-opts flag which almost certainly doesn't matter because you > were almost certainly not using it. > > Nickif (LinkAsLibrary) { ... if (TheLinker.LinkInFiles(Files)) ... else { ..... // Link all the items together if (TheLinker.LinkInItems(Items, NativeLinkItems) ) I don't think that LinkInFiles () and LinkInItems () do the same thing. - Sanijv