John Emmas via llvm-dev
2021-Sep-23 14:18 UTC
[llvm-dev] Disabling inline compilation (Clang with VS2019)
On 23/09/2021 14:50, Hans Wennborg wrote:> extern int __declspec(dllimport) x; > inline int __declspec(dllimport) get_x() { return x; } > int f() { return get_x(); } > > int __declspec(dllimport) foo(); > inline int __declspec(dllimport) bar() { return foo(); } > int g() { return bar(); } > > MSVC 19.21 will inline the get_x() and bar() calls, but 19.22 will > not: https://godbolt.org/z/n1cedv3a8 > > Clang matches the 19.21 behaviour. The way it checks whether a > dllimport function is safe to inline is whether it only references > symbols which are also dllimport (the logic lives in > CodeGenModule::shouldEmitFunction()). > > It seems that MSVC has become more conservative here. We could update > Clang to behave similarly, but it would be good to understand the > exact motivation. >Many thanks for the contributions here. I often post on the MS Developer forum so I'll ask for clarification there - and I'll post back if I get any replies (though bear in mind that replies can sometimes take a long time there!!) I've used MSVC for maybe 20 years and I've never once known a DLL function to be inline-able. So my guess (though it is just a guess) is that something maybe went awry in 19.21 and then got corrected in 19.22. Best regards, John
John Emmas via llvm-dev
2021-Sep-23 15:03 UTC
[llvm-dev] Disabling inline compilation (Clang with VS2019)
On 23/09/2021 15:18, John Emmas via llvm-dev wrote:> > I've used MSVC for maybe 20 years and I've never once known a DLL > function to be inline-able. >On 23/09/2021 15:07, Hans Wennborg wrote:> Actually, MSDN (https://docs.microsoft.com/en-us/cpp/cpp/defining-inline-cpp-functions-with-dllexport-and-dllimport) > documents the opposite: > > "You can also define as inline a function declared with the dllimport > attribute. In this case, the function can be expanded (subject to /Ob > specifications)" > > Of course the reality is more complicated, but it's clear MSVC never > excluded dllimport functions from inlining in general. >Ah... maybe that's the situation - perhaps a DLL function CAN be inlined but only if it's specifically declared as such? That makes a lot of sense and it would also explain why I've never seen it here with ordinary DLL declarations (i.e. those not declared using inline) John
Hans Wennborg via llvm-dev
2021-Sep-23 18:00 UTC
[llvm-dev] Disabling inline compilation (Clang with VS2019)
On Thu, Sep 23, 2021 at 4:18 PM John Emmas via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 23/09/2021 14:50, Hans Wennborg wrote: > > extern int __declspec(dllimport) x; > > inline int __declspec(dllimport) get_x() { return x; } > > int f() { return get_x(); } > > > > int __declspec(dllimport) foo(); > > inline int __declspec(dllimport) bar() { return foo(); } > > int g() { return bar(); } > > > > MSVC 19.21 will inline the get_x() and bar() calls, but 19.22 will > > not: https://godbolt.org/z/n1cedv3a8 > > > > Clang matches the 19.21 behaviour. The way it checks whether a > > dllimport function is safe to inline is whether it only references > > symbols which are also dllimport (the logic lives in > > CodeGenModule::shouldEmitFunction()). > > > > It seems that MSVC has become more conservative here. We could update > > Clang to behave similarly, but it would be good to understand the > > exact motivation. > > > > Many thanks for the contributions here. I often post on the MS > Developer forum so I'll ask for clarification there - and I'll post back > if I get any replies (though bear in mind that replies can sometimes > take a long time there!!)Thanks! It would be interesting to learn why this changed. (I can only come up with obscure reasons right now.)> I've used MSVC for maybe 20 years and I've never once known a DLL > function to be inline-able. So my guess (though it is just a guess) is > that something maybe went awry in 19.21 and then got corrected in > 19.22. Best regards,On the godbolt example above, I was able to try back to MSVC 19.14 (I think that's Visual Studio 2017 version 15.7) and it also shows inlining. Same with Visual Studio 2013 which is the oldest version I have locally. I think generally developers shouldn't notice this though, since both MSVC and Clang are careful only to inline dllimport functions when they only reference symbols which are also dllimport, and things should just work. For that reason, I don't understand why your code isn't working. The way it's written, _the_keyboard should get exported from the DLL, and the fact that it's not is a mystery. If you could provide an example with code both for building the DLL and EXE which reproduces the link error (even if the DLL has to be built with MSVC and the exe with Clang), that would be useful. Thanks, Hans