llvm dev - Sep 2021 - 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

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

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