[LLVMdev] Any mechanism available for link time inlineing?

Duncan P. N. Exon Smith
Mon, 16 Feb 2015 19:44:21 -0000

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