On Sun, Jun 29, 2025, 4:42 PM Andrew Pinski <pins...@gmail.com> wrote:
> > > On Sun, Jun 29, 2025, 4:36 PM Antoni Boucher <boua...@zoho.com> wrote: > >> >> >> Le 2025-06-29 à 10 h 46, Andrew Pinski a écrit : >> > >> > >> > On Sun, Jun 29, 2025, 7:43 AM Andrew Pinski <pins...@gmail.com >> > <mailto:pins...@gmail.com>> wrote: >> > >> > On Sun, Jun 29, 2025, 7:36 AM Antoni Boucher via Gcc >> > <gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>> wrote: >> > >> > Hi. >> > Is there a way in GENERIC to specify that a parameter will be >> > passed in >> > "sret", or is this solely controlled by the hook >> struct_value_rtx? >> > >> > >> > It is only controlled by the hook. >> > What exactly are trying to do? >> > You could set the return slot optimization bit on the call >> > expression if you want the lhs of a call not to be copied and just >> > passed as the address via sret. >> >> I'm trying to follow the Rust ABI for rustc_codegen_gcc: they manually >> specify whether a param is "sret". >> > > Not all ABI/targets have a sret specific register. So this is even more > confusing. > So I looked into this further, it is not rust that specifies sret but rather rust transformation into llvm code generation that does that. So you need to explain what exactly what you need. So in the case of gcc generic (and gimple), the IR is independent of the abi and higher level than the LLVM IR (think more what MLIR is closer to gimple these days and LLVM IR is closer to rtl) . So if you have: var = func(...); Expand will always the right thing based on what the target says how the type is returned. But this will introduce a memory copy unless you set RSO bit of the call expression. Thanks, Andrew > > >> > >> > That is if you have: >> > StructVar = func(...); >> > >> > You set the return slot optimization bit on the call expr in generic >> > and which will copy that bit to the gimple GIMPLE_CALL and then >> > during expand will again copy it back to the generic call_expr and >> > expand will use the target for the address. >> > >> > >> > CALL_EXPR_RETURN_SLOT_OPT is the macro. >> >> Is this a guaranteed optimization? I'm asking because this is for ABI >> correctness and I need a solution that will always work. >> If not, would there be another way to do this? >> Thanks. >> > > Yes it is guaranteed that if the return type is returned via memory > reference to the other function it will use that memory location. > > Even for things like a->b = func(...)[RSO]. It is even used by the c++ > frontend that way. > > > >> > >> > >> > >> > Is that what you are looking for? >> > >> > >> > Thanks, >> > Andrew >> > >> > Thanks. >> > >> >>
