[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)
John McCall via cfe-commits
cfe-commits at lists.llvm.org
Wed May 29 17:07:43 PDT 2024
================
@@ -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
More information about the cfe-commits
mailing list