================
@@ -5348,18 +5348,8 @@ Value *ScalarExprEmitter::VisitVAArgExpr(VAArgExpr *VE) {
return llvm::UndefValue::get(ArgTy);
}
- // FIXME Volatility.
- llvm::Value *Val = Builder.CreateLoad(ArgPtr);
-
- // If EmitVAArg promoted the type, we must truncate it.
- if (ArgTy != Val->getType()) {
- if (ArgTy->isPointerTy() && !Val->getType()->isPointerTy())
- Val = Builder.CreateIntToPtr(Val, ArgTy);
- else
- Val = Builder.CreateTrunc(Val, ArgTy);
- }
-
- return Val;
+ return CGF.EmitLoadOfScalar(ArgPtr, Ty.isVolatileQualified(), Ty,
+ VE->getExprLoc());
----------------
rjmccall wrote:
The new code pattern is just casting the address to the load/store type of the
expression type, right? That seems like it'd be wrong on big-endian targets if
the variadic argument was promoted. `EmitVAArg`, in its wisdom, is giving us
the address of something in the `va_list` and then not telling what type it is
other than as the element type of the returned address.
Are `_BitInt`s ever promoted as variadic arguments? I guess that would be up
to the target, right? It really feels like `EmitVAArg` needs to be giving us
an actual type for the l-value it's returning, or (better yet?) just returning
an `RValue` instead of forcing the caller to handle demotion.
I agree it would be better to do that in a separate patch.
https://github.com/llvm/llvm-project/pull/91364
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
