Nick Lewycky
2015-Feb-15 04:25 UTC
[LLVMdev] Any mechanism available for link time inlineing?
mobi phil wrote:> thanks, sounds great, heard about llvm-lto, but was not following in > details. I have an llvm-lto in my dev branch build....now what I do not > find are some example on how to use it for link time inline-ing. In > worst case have to deal with the overhead to experimentWith what linker? LLVM LTO is available by default with Apple's XCode development environment, just specify -O4. For linux or similar, see llvm.org/docs/GoldPlugin.html . You may be able to just use -O4 on linux too, depending on how your llvm and linker are installed, and assuming you run "clang" for your link steps. Inlining occurs because it's a standard part of the link time optimization pipeline. If you need to turn off the rest of LTO, reducing it down to only inlining, that would take more work. Nick
Tim Northover
2015-Feb-15 04:36 UTC
[LLVMdev] Any mechanism available for link time inlineing?
> LLVM LTO is available by default with Apple's XCode development environment, > just specify -O4.I'm not sure exactly what -O4 does these days, but it's not the suggested way of doing LTO. For that you should pass "-flto" with a more normal optimisation level. Cheers. Tim.
Duncan P. N. Exon Smith
2015-Feb-15 22:35 UTC
[LLVMdev] Any mechanism available for link time inlineing?
> On 2015 Feb 14, at 20:36, Tim Northover <t.p.northover at gmail.com> wrote: > >> LLVM LTO is available by default with Apple's XCode development environment, >> just specify -O4. > > I'm not sure exactly what -O4 does these days, but it's not the > suggested way of doing LTO. For that you should pass "-flto" with a > more normal optimisation level. >To add to what Nick and Tim have said: `llvm-lto` is more of a debugging tool (for testcases, repros, etc.) than anything else. Unless you're looking to contribute to LTO, you should be strictly using `clang -flto`.
Duncan P. N. Exon Smith
2015-Feb-16 19:44 UTC
[LLVMdev] Any mechanism available for link time inlineing?
+llvmdev (I assume you dropped the list by accident?)> On 2015-Feb-16, at 05:11, mobi phil <mobi at mobiphil.com> wrote: > > Thanks for the feedback. I think this is a valuable detail lot of people do not know about it. As described above was playing with the idea of a PIMPL like C++ language extension where parts of the class (mainly the data layout) would be moved away from the header into the source file. Public data members would be accessed through setters/getters but in some cases this could mean an annoying overhead of a function call. However with lto (inline) this problem is solved! > > I did not find any roadmap about lto development. Is this supposed to become a standard?There are still some issues with LTO on projects that are large or that need different subtargets for different compile units. We're actively working on improving it though.> Not so important, but this idea is itchy in my brain: based on your experience with lto, optimizers, what would be the pitfalls for implementing such inlining at dynamic linking. The use case would be straightforward: given a main executable with some unresolved function symbols, inline functions instead of dynamic link. In order to be fast such dynamic-inlining would probably ignore any strategy to see if inlining would result in code-bloat etc.This sounds more like load-time optimization than link-time. I don't think our model would work well there. CodeGen is too expensive.