[llvm-dev] Disabling inline compilation (Clang with VS2019)

Hans Wennborg via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 23 11:00:05 PDT 2021


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


More information about the llvm-dev mailing list