<div dir="ltr"><div dir="ltr">On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users <<a href="mailto:cfe-users@lists.llvm.org">cfe-users@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/09/2021 18:21, Reid Kleckner via cfe-users wrote:<br>
> Looking back in the thread, I found the example code, and I see that <br>
> MSVC refuses to inline this helper, but clang will inline it. I <br>
> believe clang is permitted to inline it, MSVC will export the static <br>
> data member (_the_keyboard), so everything should work as long as you <br>
> provide a definition of _the_keyboard in the DLL and set -DBUILDING_DLL.<br>
><br>
<br>
Thanks for coming in on this, Reid. As Jeff suggested, I transferred the <br>
question to llvm-dev where there's a small discussion going on now.  I <br>
must admit though, my personal view is that declaring something as <br>
__declspec(dllimport) should automatically exclude it from being inlined <br>
(I'm pretty sure that's what Microsoft itself does...)<br>
<br>
Ultimately, the main advantage of a DLL is that it offers dynamic <br>
linkage. In other words, DLL features can be updated simply by updating <br>
the DLL (i.e. without needing to update all the apps which use it). In <br>
the dim old days this could lead to something called "DLL Hell" but <br>
WinSxS has largely consigned that to history now.  So whilst inlining <br>
code from a DLL might seem like a good idea, it throws away the main <br>
advantage of DLL's without offering anything better.<br></blockquote><div><br>Presumably it offers the benefit of inlining optimizations - so there's probably some execution speed improvement to tradeoff. (& a way the user can address the issue by moving functions out of line)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Over on llvm-dev I'm trying to persuade them that declaring something as <br>
__declspec(dllimport) should automatically exclude it from being <br>
inlined.  And to be honest, I'd be quite surprised if that's not what <br>
Microsoft intended.<br></blockquote><div><br>I think if it's clearly demonstrated that that's Microsoft's implementation - that no matter how hard you ask it to optimize and how simple the function is, that it won't inline a dllexported function that's inline in a header (both implicitly inline in a class definition, and probably check the case of a standalone dllexported inline non-member function in a header) that I'd say (though I have little sway/weight in this design decision) clang-cl should implement the same behavior, because it is observable/can be relied upon as you have (though also - dllexported variables should be defined somewhere, generally) & an opt-in flag to what is the current behavior (dllexport-inlining).<br><br>- Dave</div></div></div>