[LLVMdev] Any mechanism available for link time inlineing?

[Duncan P. N. Exon Smith]

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