<div dir="ltr">Hi Richard (& others),<br><br>As a tangent from: <a href="http://clang-developers.42468.n3.nabble.com/Could-we-emit-inline-virtual-member-functions-as-available-externally-when-there-s-a-key-function-sa-td4051908.html">http://clang-developers.42468.n3.nabble.com/Could-we-emit-inline-virtual-member-functions-as-available-externally-when-there-s-a-key-function-sa-td4051908.html</a><br><br>I'm trying to see whether we can go further than that: Specifically, emitting even non-virtual inline functions for dynamic classes alongside the class's vtable (& omitting them elsewhere (except when optimizations are enabled, and then emitting them available_externally))<br><br>I tried the attached patch as a total scrappy hack to get numbers. It only implements one side of this (well, first it implements the ABI-breaking but language-conforming thing mentioned in the original thread, of doing inline virtual functions the same as the vtable) by omitting the definition of inline member functions of a type with a vtable where the vtable isn't emitted. It does emit strong definitions of any inline function that is used in the TU where the vtable is emitted - but fails to emit the strong definitions otherwise.<br><br>So at best, if I look at object size when using this patch, I should see a greater benefit than is actually possible (the benefit will shrink once the strong definitions are properly emitted).<br><br>Does this patch look even approximately right for that task? For my small test cases it seems to be, and judging by the linker errors it looks like it's doing approximately the right thing in larger test cases.<br><br>But I'm only seeing about a 2% reduction in object size over a large binary, which seemed surprisingly low. Plausible? Is this obviously missing some opportunities? Any ideas on ways I could investigate this further?<br><br>- Dave</div>