Quuxplusone added a comment.
> You're right; thinking about it in the context of four value operations is
> helpful.
FWIW, I think dragging "value operations" into the mix is exactly wrong (and
referring to "destructive move" is extra wrong, in the specific context of
C++). For a C++ object, we do have language-level operations for "original
initialization, copy, and destruction" (I'm willing to grant that "move" is
just a special form of "copy"); but we don't have "destructive move," neither
at the language level nor at the ABI level. `[[trivial_abi]]` isn't about
//language//-level operations at all. It's about granting the compiler the
freedom to //make up and insert// bitwise-teleportations of the object from
point A to point B, //even when the language spec says no operation is
happening.// So for example, in C++, if we have `struct T { T() { print(this);
} }; void f(T a) { print(&a); }`, and we do `f(T())`, there is no "copy"
happening — from C++'s point of view, there is only one `T` constructor called.
However, the pointer value printed inside `T()` is permitted to be
//different// from the pointer value printed inside `f` — basically, after the
`T` object is "constructed," it gets bitwise-teleported to a different location
in memory, //without being copied, moved, or anything else// at the language
level. https://godbolt.org/z/e6hzPP
You can see that the code still compiles even when `T`'s copy and move
operations are deleted. https://godbolt.org/z/hfr14v This is because those
operations //are not happening//, at the C++ language level. As far as C++ is
concerned, we've got just one `T` object. We're not
destroying-it-and-moving-it-elsewhere; that'd be the "relocation" operation
described in my P1144 <https://wg21.link/p1144> and D50119
<https://reviews.llvm.org/D50119>. A `[[trivially_relocatable]]` type permits
the compiler to //replace// single pairs of "copy" and "destroy" operations
with "bitwise-teleports." A `[[trivial_abi]]` type, on the other hand, permits
the compiler to act at the //ABI// level and //insert// arbitrarily many
"bitwise-teleport" operations even when the language spec calls for the object
to remain in one place.
FWIW, (1) I doubt there's any reason to permit immovable objects to be
`[[trivial_abi]]`; (2) I wish this attribute worked more like D50119
<https://reviews.llvm.org/D50119> `[[trivially_relocatable]]` and less like
D50119 <https://reviews.llvm.org/D50119> `[[maybe_trivially_relocatable]]` (but
I know @rjmccall feels exactly the opposite way). IMO, if the attribute simply
meant "yes this thing is trivial for purposes of ABI and you can
bitwise-teleport it whenever you like, full stop," then you wouldn't need to
have these intricate discussions on precisely how triviality should be
inherited in different situations — it would all "just work," as naturally as
`[[trivially_relocatable]]`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D92361/new/
https://reviews.llvm.org/D92361
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
