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

via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 23 07:17:54 PDT 2021



> -----Original Message-----
> From: Hans Wennborg <hans at chromium.org>
> Sent: Thursday, September 23, 2021 10:07 AM
> To: Robinson, Paul <paul.robinson at sony.com>
> Cc: john at creativepost.co.uk; llvm-dev at lists.llvm.org; rnk at google.com
> Subject: Re: [llvm-dev] Disabling inline compilation (Clang with VS2019)
> 
> > > If MSVC promises not to inline a dllimport method, that seems like
> > > something Clang should take into consideration in MS-compatibility
> > > mode.  Probably implicitly marking dllimport methods as noinline would
> > > be sufficient, but I think we'd be willing to do that only if MSVC
> > > actually makes that promise explicitly.
> > > --paulr
> >
> > I don't believe MSVC makes such a promise
> 
> Actually, MSDN (https://urldefense.com/v3/__https://docs.microsoft.com/en-
> us/cpp/cpp/defining-inline-cpp-functions-with-dllexport-and-
> dllimport__;!!JmoZiZGBv3RvKRSx!oov0npYXltSa48-5jB1s-
> uoThwsPWz6RzPFNJrtn2hF9gPQ6djpSs1u5VBzq03XTCA$ )
> 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.

On the other hand, the experience described upthread is that Clang's
handling of /Ob0 still permits inlining.  The MSDN quote suggests that
/Ob0 should suppress inlining, and that's not what people see.
--paulr



More information about the llvm-dev mailing list