================
@@ -1319,14 +1319,66 @@ static llvm::Value
*CoerceIntOrPtrToIntOrPtr(llvm::Value *Val, llvm::Type *Ty,
/// This safely handles the case when the src type is smaller than the
/// destination type; in this situation the values of bits which not
/// present in the src are undefined.
-static llvm::Value *CreateCoercedLoad(Address Src, llvm::Type *Ty,
+static llvm::Value *CreateCoercedLoad(Address Src, QualType SrcFETy,
+ llvm::Type *Ty,
CodeGenFunction &CGF) {
llvm::Type *SrcTy = Src.getElementType();
// If SrcTy and Ty are the same, just do a load.
if (SrcTy == Ty)
return CGF.Builder.CreateLoad(Src);
+ // Coercion directly through memory does not work if the structure has
pointer
+ // field protection because the struct in registers has a different bit
+ // pattern to the struct in memory, so we must read the elements one by one
+ // and use them to form the coerced structure.
+ std::vector<PFPField> PFPFields;
+ CGF.getContext().findPFPFields(SrcFETy, CharUnits::Zero(), PFPFields, true);
----------------
ojhunt wrote:
This should be done by generating a copy thunk and calling that, rather than
performing this logic repeatedly, and more importantly regenerating it
repeatedly. If the update function is small enough it will be inlined, and if
it's not you probably do not want a large number of copies of the code.
Your intent appears to be to maintain the register transfer abi for POD types,
despite the objects logically no longer being POD types - which isn't
unreasonable given that the current design means that all structs containing
pointers would become non-POD, which is probably suboptimal - but if you are
doing so, because a large enough struct can spill, I'd recommend you adopt a
model where the PFP fields in a return or parameter copy of the object are
tagged specifically as transfer fields, something akin to `hash(argument
position || PFP offset || some_this_is_a_transfer_constant)`.
https://github.com/llvm/llvm-project/pull/133538
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
