[cfe-dev] Inlining dllimport functions

[Reid Kleckner via cfe-dev]

That would be a shame. I wouldn't want to throw away such an important code
size optimization just because we can't export the things the inline
functions reference.

I understand it's tough, though. libc++'s visibility and export macros have
many consumers, many vendors, many linkage models, and basically too many
cooks in the kitchen. I don't have any brilliant suggestions for solving
that.

On Thu, Sep 13, 2018 at 1:05 PM Hamza Sood <hamza_sood at me.com> wrote:

> I’ve looked into it a bit more and it seems like the main optimisation
> barrier with libc++ on Windows is the extern template usage; it’s
> preventing a lot of trivial inlining. What about making
> _LIBCPP_DISABLE_EXTERN_TEMPLATE the default for Windows DLL builds?
>
> On 13 Sep 2018, at 17:23, Reid Kleckner wrote:
>
> It would cause problems if 'f' in turn referenced functions that were
> neither inline nor exported:
>
> bool not_exported();
> inline bool f() { return not_exported(); }
> __declspec(dllimport) inline bool g() { return f(); }
>
> I'm pretty sure MSVC will not inline g in this or your example, so I would
> suggest adjusting dllimport usage patterns to something that satisfies both
> compilers rather than changing clang.
>
> On Thu, Sep 13, 2018 at 8:43 AM Hamza Sood via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Currently, Clang won’t inline a dllimport function that references a
>> non-dllimport function. This has a big performance impact on using libc++
>> on Windows because even something as simple as vector::data() won’t be
>> inlined at the max optimisation level.
>>
>> Would anything break if Clang were to allow inlining of a dllimport
>> function that references a non-dllimport function that’s also declared
>> inline?
>>
>> E.g:
>>
>> inline bool f() { return false; }
>>
>> __declspec(dllimport) inline bool g() { return f(); }
>>
>> bool h() {
>>   // can we inline this without issue?
>>   return g();
>> }
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180913/492865a5/attachment.html>