The attribute means that the user has to micro-manage individual
function parameters. One more thing to worry about.
If gcc/clang users[1] don't like the Linux ABI's choice of
destroying the parameter at the end of the enclosing
full-expression, then they should contribute patches to the
Itanium ABI and gcc/clang to allow opting-in to a new ABI where
parameters are destroyed at the end of a function. I don't think
the Standard should work around deficiencies in some
implementations that can be fixed completely within the scope of
those implementations.
[1] I'm one of them.
This doesn’t really need to be a question of explicitly changing the ABI, the standard says:
It is implementation-defined whether the lifetime of a parameter ends when the function in which it is defined returns or at the end of the enclosing full-expression.
This proposal would just define the lifetimes of parameters with a particular tag/attribute. I’d probably use an attribute not a keyword, adding an attribute can be an ABI breaking change, see no_unique_address.
Jonathan
On 7 Aug 2022, at 15:21, Avi Kivity via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On 29/07/2022 21.42, Arthur O'Dwyer via Std-Proposals wrote:
On Fri, Jul 29, 2022 at 2:26 PM Marcin Jaczewski <marcinjaczewski86@gmail.com> wrote:
pt., 29 lip 2022 o 20:20 Arthur O'Dwyer <arthur.j.odwyer@gmail.com> napisał(a):
>
> On Thu, Jul 28, 2022 at 5:26 PM Marcin Jaczewski via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>>
>> Currently there are multiple problems linked to lifetime of function parameters.
>> Simply current default behavior does not fit all corner cases.
>>
>> Example is `std::unique` that generates subpar code because the call
>> site is a firewall that prevents the compiler to see at once destructor and move operation.
>
>
> Can you elaborate on this? I admit I've never thought about `std::unique` in this context before; but now that I have spent an hour or so thinking about it, I still don't see how its current behavior can be improved. One might rewrite `std::unique` to use swap instead of move-assignment, but one can't really rewrite it to use relocation because `std::unique` is never responsible for destroying anything. N objects go in, N objects come out (and in the same memory locations, too).
> https://p1144.godbolt.org/z/8v1Yj1eGK
>
> What would you do differently here?
>
Sorry, I mistyped, I mean type `std::unique_ptr` not algorythm `std::unique`.
Aha. In that case, is your proposal any different from the existing attribute [[trivial_abi]]?
([[trivial_abi]] is vendor-specific, not part of the ISO standard; but if your proposal really just boils down to "Hey, WG21 should just standardize [[trivial_abi]]," then you should say that.)
IMO, that's wrong. The standard leaves the ABI to the implementation. Standardizing [[trivial_abi]] means the standard acknowledges multiple ABIs, and requires the user to micro-manage the ABI of each type if they care about performance.
The implementations should just switch to a better ABI - callee-destroy, and pass-by-register if it can prove no self-references are involved (e.g. by type-based alias analysis, trivial for std::unique_ptr).
Yes, switching ABIs is a huge pain, but it has been managed in the past. gcc switched from reference-counted std::string to non-reference-counted std::string with SBO, and there were minor ABI updates when bugs were found in the implementation. The implementations are stuck in a deep hole, but [[trivial_abi]] makes that hole a little deeper.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals