Date: Thu, 02 Nov 2023 10:18:01 +0800
>> On 1 Nov 2023, at 15:19, Steve Downey via SG15 <sg15_at_lists.isocpp.org> wrote:
>>
>> We spent a lot of time litigating this in the C++20 time frame, particularly the impact of function definitions being visible or not.
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html > and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html > are relevant.
>> Non-inline function definitions are not to be exported as part of the module interface. Module implementers control the ABI of the module, even without module implementation partitions. The presence of the `inline` keyword has extra meaning in a module interface, and signals that the body is available.
Oh, yeah, previously I thought the P1779R3 paper is going to make member functions in module purview not implicitly inline any more and I thought this is already implemented in clang. And I thought EWG papers are primarily for semantics and they are irrevelent with BMI or ABI things. But after reconsidering the intention for the papers, it is indeed an implicit goal to not make the non-inline function bodies to be part of the ABI of the modules consumers. Then clang's behavior with optimization enabled is a bug.
> So, in fact, it appears clang has a bug here (at least, in that the emitted body is reachable by importers).
Yes, I am going to fix this.
Many Thanks,
Chuanqi
------------------------------------------------------------------
From:Iain Sandoe via SG15 <sg15_at_[hidden]>
Send Time:2023 Nov. 1 (Wed.) 23:34
To:sg15 Iain Sandoe via <sg15_at_[hidden]pp.org>
Cc:Iain Sandoe <iain_at_[hidden]>
Subject:Re: [SG15] [P3033] Should we import function bodies to get better optimizations?
> On 1 Nov 2023, at 15:19, Steve Downey via SG15 <sg15_at_[hidden]> wrote:
>
> We spent a lot of time litigating this in the C++20 time frame, particularly the impact of function definitions being visible or not.
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html > and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html > are relevant.
> Non-inline function definitions are not to be exported as part of the module interface. Module implementers control the ABI of the module, even without module implementation partitions. The presence of the `inline` keyword has extra meaning in a module interface, and signals that the body is available.
So, in fact, it appears clang has a bug here (at least, in that the emitted body is reachable by importers).
As far as I understand, MSVC and GCC both omit the function body from the interface in the non-inline case.
> This has the tradeoff that the translated interface is not sufficient alone to compile the module TU because it is incomplete.
Well, that is no different from any other ‘externally-available’ function, so I’m not sure I consider it a significant trade-off.
We have other mechanisms for improving the runtime-performance of such cases (i.e. LTO) while that is not always used, it is an option.
We have also informally discussed more sophisticated schemes where optimized implementation data are carried along with the BMI in some larger and more sophisticated container (but that is very much something for the future, along with the potential multi-phased idea).
Iain
> On Wed, Nov 1, 2023 at 10:18 AM Daniel Ruoso via SG15 <sg15_at_[hidden]> wrote:
> On Wed, Nov 1, 2023, 03:10 Mathias Stearn via SG15 <sg15_at_[hidden]> wrote:
> I'd rather we leave the option of whether I care more about rebuilds and ABI stability vs optimization to then end project doing the compilation rather than mandating a specific set of tradeoffs
>
> The underlying problem is deeper than that.
>
> We have a multi-vendor ecosystem. A library author releasing a pre-built library needs to manage the ABI compatibility when making changes to that library.
>
> That means it is imperative to have a definitive consistent answer to the question of "does this change require me to make a new SONAME for my library?".
>
> Library authors that want to preserve ABI compatibility across releases need to use various techniques in order to allow changes without breaking compatibility (see also "How to write shared libraries", by Ulrich Drepper).
>
> Module interface units introduce a new category for C++ code, as now we have non-inline functions that are technically available to the caller. Before modules, only inline functions could be visible to the call site.
>
> There are two options:
>
> 1) non inline functions are visible to callers, which means they need to be treated as if they were inline for the purpose of managing compatibility.
>
> 2) non inline functions are not visible to callers, which means changes to their bodies have no impact on backwards compatibility.
>
> I have no strong opinion one way or another. My only strong opinion is that this has to be a consensus in the entire ecosystem, and properly documented and communicated, so library authors can decide if they should put a non-inline function in the interface unit or move it to an implementation unit.
>
> Daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
_______________________________________________
SG15 mailing list
SG15_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
>>
>> We spent a lot of time litigating this in the C++20 time frame, particularly the impact of function definitions being visible or not.
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html > and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html > are relevant.
>> Non-inline function definitions are not to be exported as part of the module interface. Module implementers control the ABI of the module, even without module implementation partitions. The presence of the `inline` keyword has extra meaning in a module interface, and signals that the body is available.
Oh, yeah, previously I thought the P1779R3 paper is going to make member functions in module purview not implicitly inline any more and I thought this is already implemented in clang. And I thought EWG papers are primarily for semantics and they are irrevelent with BMI or ABI things. But after reconsidering the intention for the papers, it is indeed an implicit goal to not make the non-inline function bodies to be part of the ABI of the modules consumers. Then clang's behavior with optimization enabled is a bug.
> So, in fact, it appears clang has a bug here (at least, in that the emitted body is reachable by importers).
Yes, I am going to fix this.
Many Thanks,
Chuanqi
------------------------------------------------------------------
From:Iain Sandoe via SG15 <sg15_at_[hidden]>
Send Time:2023 Nov. 1 (Wed.) 23:34
To:sg15 Iain Sandoe via <sg15_at_[hidden]pp.org>
Cc:Iain Sandoe <iain_at_[hidden]>
Subject:Re: [SG15] [P3033] Should we import function bodies to get better optimizations?
> On 1 Nov 2023, at 15:19, Steve Downey via SG15 <sg15_at_[hidden]> wrote:
>
> We spent a lot of time litigating this in the C++20 time frame, particularly the impact of function definitions being visible or not.
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1498r1.html > and https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1779r3.html > are relevant.
> Non-inline function definitions are not to be exported as part of the module interface. Module implementers control the ABI of the module, even without module implementation partitions. The presence of the `inline` keyword has extra meaning in a module interface, and signals that the body is available.
So, in fact, it appears clang has a bug here (at least, in that the emitted body is reachable by importers).
As far as I understand, MSVC and GCC both omit the function body from the interface in the non-inline case.
> This has the tradeoff that the translated interface is not sufficient alone to compile the module TU because it is incomplete.
Well, that is no different from any other ‘externally-available’ function, so I’m not sure I consider it a significant trade-off.
We have other mechanisms for improving the runtime-performance of such cases (i.e. LTO) while that is not always used, it is an option.
We have also informally discussed more sophisticated schemes where optimized implementation data are carried along with the BMI in some larger and more sophisticated container (but that is very much something for the future, along with the potential multi-phased idea).
Iain
> On Wed, Nov 1, 2023 at 10:18 AM Daniel Ruoso via SG15 <sg15_at_[hidden]> wrote:
> On Wed, Nov 1, 2023, 03:10 Mathias Stearn via SG15 <sg15_at_[hidden]> wrote:
> I'd rather we leave the option of whether I care more about rebuilds and ABI stability vs optimization to then end project doing the compilation rather than mandating a specific set of tradeoffs
>
> The underlying problem is deeper than that.
>
> We have a multi-vendor ecosystem. A library author releasing a pre-built library needs to manage the ABI compatibility when making changes to that library.
>
> That means it is imperative to have a definitive consistent answer to the question of "does this change require me to make a new SONAME for my library?".
>
> Library authors that want to preserve ABI compatibility across releases need to use various techniques in order to allow changes without breaking compatibility (see also "How to write shared libraries", by Ulrich Drepper).
>
> Module interface units introduce a new category for C++ code, as now we have non-inline functions that are technically available to the caller. Before modules, only inline functions could be visible to the call site.
>
> There are two options:
>
> 1) non inline functions are visible to callers, which means they need to be treated as if they were inline for the purpose of managing compatibility.
>
> 2) non inline functions are not visible to callers, which means changes to their bodies have no impact on backwards compatibility.
>
> I have no strong opinion one way or another. My only strong opinion is that this has to be a consensus in the entire ecosystem, and properly documented and communicated, so library authors can decide if they should put a non-inline function in the interface unit or move it to an implementation unit.
>
> Daniel
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
_______________________________________________
SG15 mailing list
SG15_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15 <https://lists.isocpp.org/mailman/listinfo.cgi/sg15 >
Received on 2023-11-02 02:18:08