[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


================
@@ -1533,9 +1533,17 @@ void CodeGenFunction::EmitReturnStmt(const ReturnStmt &S) {
     Builder.CreateStore(Result.getScalarVal(), ReturnValue);
   } else {
     switch (getEvaluationKind(RV->getType())) {
-    case TEK_Scalar:
-      Builder.CreateStore(EmitScalarExpr(RV), ReturnValue);
-      break;
+    case TEK_Scalar: {
+      llvm::Value *Ret = EmitScalarExpr(RV);
+      // EmitStoreOfScalar could be used here, but it extends bool which for
+      // some targets is returned as i1 zeroext.
----------------
rjmccall wrote:

Well, we don't normally have to expose the address of `ReturnValue` with scalar results, so we *could* avoid unnecessary promotions/truncations here in common cases by just making `ReturnValue` be an alloca of the scalar type instead of the for-memory type.  However, that would add complexity for the one case where `ReturnValue` *is* exposed, which is when the ABI requires the function to return indirectly; in that case, it would be important that we promote the return value before initializing the return value slot.  So there's a trade-off here: we can unconditionally treat `ReturnValue` as having the for-memory type (at the cost of emitting some extra promotions/truncations), or we can track whether we were passed it vs. just allocated internally to this function (at the cost of compiler complexity around most uses of `ReturnValue`, which is a relatively small amount of code).

https://github.com/llvm/llvm-project/pull/91364


More information about the cfe-commits mailing list