https://github.com/AlexVlx commented:
> Is this a target-independent decision? I could certainly imagine a target > with a generic AS wanting to specify that indirect return addresses (and > maybe even parameters?) should be in that rather than the alloca AS; among > other things, it would allow return values to be used to initialize objects > in arbitrary memory. In C and C-derived languages, maybe that just avoids a > memcpy, but in C++ it avoids a potentially non-trivial move. This is a good point that I had not fully considered; I'll (weakly) push back by pointing out that if a target wanted to do that, it'd have to change quite a few things because now we seem to pretty much `alloca` storage for `sret` args by default, and thus we just end up with some extra spurious AS casts / reliance on AS inference doing the right thing. However, your question made me go and look at C++ use cases, which unearthed a pretty big (general) challenge with this change: for cases where the alloca AS and the default AS differ, we can end up trying to pass an `sret` arg directly to a callee that takes a pointer to the default AS. I've added a test that exposes this and a potential fix, but I'm not hyper keen on the latter - unfortunately, I see no better way to deal with this. https://github.com/llvm/llvm-project/pull/114062 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
