C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Custom call convention per type

From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Date: Fri, 29 Jul 2022 21:08:50 +0200
pt., 29 lip 2022 o 20:43 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> napisał(a):
>
> On Fri, Jul 29, 2022 at 2:26 PM Marcin Jaczewski <marcinjaczewski86_at_[hidden]> wrote:
>>
>> pt., 29 lip 2022 o 20:20 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> napisał(a):
>> >
>> > On Thu, Jul 28, 2022 at 5:26 PM Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> 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]]?
> https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/
> https://libcxx.llvm.org//DesignDocs/UniquePtrTrivialAbi.html
> https://godbolt.org/z/f59T4Tev1
>
> ([[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.)
>
> HTH,
> Arthur

Because its not trivial :>

I remember this attribute but I miss that it alters destructor order
too. And that is the critical part for me.
Passing as register is a good property but can't be used in all cases
like strings with SBO (as it could have self referencing pointers) or
mutexes.

I could say that `[[trivial_abi]]` == `arg_destructor_in_callee` +
`[[no_unique_address]]`

Where we stretch the meaning of `[[no_unique_address]]` that we could
apply to the whole class, not only its members.

Received on 2022-07-29 19:09:02