dblaikie added a comment.
In https://reviews.llvm.org/D48426#1139823, @rnk wrote:
> `LangOpts.ModulesCodegen` is very related in spirit to this, but I think we
> need a distinct option because that was designed to handle all inline
> functions (too much), not just dllexport inline functions. + @dblaikie
Does it have to be only the dllexported inline functions - or could this be
used to home all inline functions? (I guess not - presumably it's not
acceptable for the compiler to implicitly promote something to dllexport (& if
it doesn't do that promotion, then the function wouldn't be visible from the
use))
Is it valid to provide a definition for optimization purposes (LLVM's
available_externally linkage) for these inline functions? Or is it required
that, after a change to the header (modifying the implementation of one of
these dllexported inline functions), the DLL they're exported could be rebuilt
without rebuilding the clients & the change in behavior would be correctly
applied?
================
Comment at: test/CodeGen/pch-dllexport.cpp:22
+// PCH: define weak_odr dso_local dllexport x86_thiscallcc void
@"?bar@S@@QAEXXZ"
+// PCHWITHOBJ-NOT: define weak_odr dso_local dllexport x86_thiscallcc void
@"?bar@S@@QAEXXZ"
+};
----------------
This is a pretty specific "NOT" - maybe:
define {{.*}}@"?bar@...
would be better to ensure no definition is provided? (similarly above)
Also, should this file have some non-exported inline functions to check those
do the right thing?
https://reviews.llvm.org/D48426
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
