[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