Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
On 22/09/2021 18:21, Reid Kleckner via cfe-users wrote: Looking back in the thread, I found the example code, and I see that MSVC refuses to inline this helper, but clang will inline it. I believe clang is permitted to inline it, MSVC will export the static data member (_the_keyboard), so everything should work as long as you provide a definition of _the_keyboard in the DLL and set -DBUILDING_DLL. Thanks for coming in on this, Reid. As Jeff suggested, I transferred the question to llvm-dev where there's a small discussion going on now. I must admit though, my personal view is that declaring something as __declspec(dllimport) should automatically exclude it from being inlined (I'm pretty sure that's what Microsoft itself does...) Ultimately, the main advantage of a DLL is that it offers dynamic linkage. In other words, DLL features can be updated simply by updating the DLL (i.e. without needing to update all the apps which use it). In the dim old days this could lead to something called "DLL Hell" but WinSxS has largely consigned that to history now. So whilst inlining code from a DLL might seem like a good idea, it throws away the main advantage of DLL's without offering anything better. Over on llvm-dev I'm trying to persuade them that declaring something as __declspec(dllimport) should automatically exclude it from being inlined. And to be honest, I'd be quite surprised if that's not what Microsoft intended. John ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users < cfe-users@lists.llvm.org> wrote: > On 22/09/2021 18:21, Reid Kleckner via cfe-users wrote: > > Looking back in the thread, I found the example code, and I see that > > MSVC refuses to inline this helper, but clang will inline it. I > > believe clang is permitted to inline it, MSVC will export the static > > data member (_the_keyboard), so everything should work as long as you > > provide a definition of _the_keyboard in the DLL and set -DBUILDING_DLL. > > > > Thanks for coming in on this, Reid. As Jeff suggested, I transferred the > question to llvm-dev where there's a small discussion going on now. I > must admit though, my personal view is that declaring something as > __declspec(dllimport) should automatically exclude it from being inlined > (I'm pretty sure that's what Microsoft itself does...) > > Ultimately, the main advantage of a DLL is that it offers dynamic > linkage. In other words, DLL features can be updated simply by updating > the DLL (i.e. without needing to update all the apps which use it). In > the dim old days this could lead to something called "DLL Hell" but > WinSxS has largely consigned that to history now. So whilst inlining > code from a DLL might seem like a good idea, it throws away the main > advantage of DLL's without offering anything better. > 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) Over on llvm-dev I'm trying to persuade them that declaring something as > __declspec(dllimport) should automatically exclude it from being > inlined. And to be honest, I'd be quite surprised if that's not what > Microsoft intended. > 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). - Dave ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
Many thanks Dave, Over on llvm-dev a contributer called Hans found this on Microsoft's MSDN site:- https://docs.microsoft.com/en-us/cpp/cpp/defining-inline-cpp-functions-with-dllexport-and-dllimport So the current theory is that Microsoft's compiler can indeed inline DLL functions - but probably only if they're specifically declared using 'inline' And I've posted a question on the MSDN Developer forum to ask if someone can clarify this for us. Fingers crossed! John ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Clang (with Visual Studio) wrongly complains about missing variables
On Thu, Sep 23, 2021 at 12:48 PM David Blaikie via cfe-users wrote: > > On Thu, Sep 23, 2021 at 3:34 AM John Emmas via cfe-users > wrote: >> ... >> Over on llvm-dev I'm trying to persuade them that declaring something as >> __declspec(dllimport) should automatically exclude it from being >> inlined. And to be honest, I'd be quite surprised if that's not what >> Microsoft intended. > > 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). I think this is the old binary compatibility problem, like exceptions crossing module boundaries. I think part of the problem is, Microsoft does not publish a specification. For years Borland had to figure it out by reverse engineering what MS was doing. I guess the situation has not gotten any better. Jeff ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
