Le 2025-06-29 à 19 h 42, Andrew Pinski a écrit :
On Sun, Jun 29, 2025, 4:36 PM Antoni Boucher <boua...@zoho.com <mailto: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> > <mailto: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> <mailto: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.> > 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.
How does this work on the side of the function declaration? Do we need to set something so that it follows the correct convention?
Thanks a lot for your help.
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. >
