[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