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.
>