================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
