[clang] __is_trivially_relocatable isn't correct on Windows

[rnk]

As implemented in https://reviews.llvm.org/D119017 and https://reviews.llvm.org/D114732, the __is_trivially_relocatable type trait is built on top of canPassInRegisters, which was never meant to implement this type trait:

llvm-project/clang/lib/AST/Type.cpp

Line 2649 in e90ec58

return RD->canPassInRegisters();

canPassInRegisters is full of various size checks that have nothing to do with trivial relocatability:

llvm-project/clang/lib/Sema/SemaDeclCXX.cpp

Lines 6909 to 6915 in 340d746

	bool isAArch64 = S.Context.getTargetInfo().getTriple().isAArch64();
	uint64_t TypeSize = isAArch64 ? 128 : 64;
	if (CopyCtorIsTrivial &&
	S.getASTContext().getTypeSize(D->getTypeForDecl()) <= TypeSize)
	return true;
	return false;

This means __is_trivial_relocatability doesn't work correctly on Windows or PS4.

There are extensive comments on the original review which I haven't read through, but it seems like the proper solution is to track trivial relocatability as a type trait, and then use that to inform whether things get passed in registers.

I think (at risk of misremembering) that I suggested the name of "canPassInRegisters", and what I think I had in mind is that we should name it something intentionally hyper-specific and low-level so that folks don't rely on it for any other purpose, but I guess that didn't work out as planned. I guess it wasn't that great of a plan in the first place.

cc @zygoloid @ssbr @zmodem @danakj

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Reid Kleckner (rnk)

As implemented in https://reviews.llvm.org/D119017 and https://reviews.llvm.org/D114732, the `__is_trivially_relocatable` type trait is built on top of `canPassInRegisters`, which was never meant to implement this type trait: https://github.com/llvm/llvm-project/blob/e90ec58b132a7244bdd8d45dd482fd78fe487f37/clang/lib/AST/Type.cpp#L2649

canPassInRegisters is full of various size checks that have nothing to do with trivial relocatability:

llvm-project/clang/lib/Sema/SemaDeclCXX.cpp

Lines 6909 to 6915 in 340d746

	bool isAArch64 = S.Context.getTargetInfo().getTriple().isAArch64();
	uint64_t TypeSize = isAArch64 ? 128 : 64;
	if (CopyCtorIsTrivial &&
	S.getASTContext().getTypeSize(D->getTypeForDecl()) <= TypeSize)
	return true;
	return false;

This means __is_trivial_relocatability doesn't work correctly on Windows or PS4.

There are extensive comments on the original review which I haven't read through, but it seems like the proper solution is to track trivial relocatability as a type trait, and then use that to inform whether things get passed in registers.

I think (at risk of misremembering) that I suggested the name of "canPassInRegisters", and what I think I had in mind is that we should name it something intentionally hyper-specific and low-level so that folks don't rely on it for any other purpose, but I guess that didn't work out as planned. I guess it wasn't that great of a plan in the first place.

cc @zygoloid @ssbr @zmodem @danakj

[zygoloid]

__is_trivially_relocatable having a false negative (eg, based on size) seems acceptable (the documentation suggests that it can have false negatives: "... is known to ..."), but having false positives (because canPassInRegisters() returns true for types that can't be conformingly passed in registers) is very concerning.

I think the logic was: "if a type can be passed in registers, then that means you can move it from one location to another via a trivial copy, because that's what happens when you pass it in registers", but we didn't take into account that the ABI might do that even in cases where it's not correct to do so!

Adding a separate but related computation for trivial relocatability seems reasonable to me. If we can implement canPassInRegisters in terms of that, that'd be great, but I worry that there'll be cases where that's wrong too.

[rnk]

Are false negatives for __is_trivially_relocatable really acceptable? I thought one of the possible applications of it would be to conditionally use realloc (or a manual memcpy) in vector when growing the storage array. (+ @cjdb since we discussed that idea).

I seem to recall that Rust cares a lot about trivial relocatability, but I don't have a good handle on what they intended to do with it. Their use cases might not tolerate false negatives. @ssbr , can you speak to that?

Ultimately, I agree, the best resolution would be to implement canPassInRegisters in terms of trivial relocatability. And, perhaps that will be on the plate of Windows support maintainers.

[ssbr]

Are false negatives for __is_trivially_relocatable really acceptable? I thought one of the possible applications of it would be to conditionally use realloc (or a manual memcpy) in vector when growing the storage array. (+ @cjdb since we discussed that idea).

Related: https://reviews.llvm.org/D119385

(It's just been really hard to put time into it. Also there were some ~events that made me pull away from it, at the time...)

As long as it's just a missing optimization that wouldn't otherwise be there, then it's surely fine. But it would not be good if we replaced a check around e.g. trivial copyability, with a check around trivial relocatability, and doing so created a regression.

I seem to recall that Rust cares a lot about trivial relocatability, but I don't have a good handle on what they intended to do with it. Their use cases might not tolerate false negatives. @ssbr , can you speak to that?

Sure, let me try to give more detail.

First off, yeah, false negatives are OK in principle for C++/Rust interop. The consequence is that C++/Rust interop becomes more painful for that type because it requires calling into C++ for constructors and operator= and the like, where it is unnecessary.

C++ and Rust's object models, when it comes to relocation and so on, differ in that a Rust assignment / initialization is always a relocation, and a C++ assignment / initialization is always an overloaded operation which runs (potentially user-defined) assignment logic.

A type which is trivially relocatable is "safe" to use in Rust in the normal Rust way, using Rust assignment, and Rust references -- it won't invoke C++ object lifetime functions, but this is allowed, because it is __is_trivially_relocatable. However, if it is not trivially relocatable, then one must use C++-like overloadable assignment/etc.. Unlike C++, this is not provided by syntactic sugar, so you need a more involved set of macros and types inside of your Rust code. For instance, you can no longer have a mutable reference to a type, like &mut T, but must instead wrap it behind a barrier which prevents relocating-assignments, as in Pin<&mut T>. And instead of let x = y, which performs a relocation, one must use some kind of in-place initializing macro that does not, such as emplace!{let x = mov(y);}.

And so the consequence of a false negative, here, is that we unnecessarily fall back to the more painful but more general mode of C++/Rust interop, instead of using a more "native" feeling approach. So eliminating the false negative is desirable, but mostly for the same reasons that a true negative is undesirable -- in any case, we'd like things to be known to be trivially relocatable.

A perhaps bigger issue from an interop POV is that it differs by platform -- the consequence being that Rust code which assumes trivial relocatability of a type might not be portable to Windows or PS4. I think that by itself is a sufficient reason to want to detach __is_trivially_relocatable from canPassInRegisters.

P.S. I've never actually been sure what the PS4 platform is. If it's literally just the PS4, I don't mind so much, but if my PlayStation®5 is included then indeed this is very unfortunate, as that means every single one of my gaming devices are going to be slower than they could be. :'(