Bind RTL to a TREE expr (Re: [Bug target/111166])

Bind RTL to a TREE expr (Re: [Bug target/111166])

[Jiufu Guo]

Hi All!

"rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111166
...
>
>
> At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so
> we can hardly fix it there.  Only a later pass could figure each of the
> insns fully define the reg.
>
> Jiufu Guo is working to improve what we choose for DECL_RTL, but for
> incoming params / outgoing return.  This is a case where we could,
> with -fno-tree-vectorize, improve DECL_RTL for an automatic var and
> choose not TImode but something like a (concat:TI reg:DI reg:DI).

Here is the patch about improving the parameters and returns in
registers.
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628213.html

I have a question about how to bind an RTL to a TREE expression.
In this patch, a map TREE->RTL is used. But it would be better if
there was a faster way.

We have DECL_RTL/INCOMING_RTL, but they can only be bound to
DECL(or PARM). In the above patch, the TREE can be an EXPR
(e.g. COMPONENT_REF/ARRAY_REF).

Is there a way to achieve this? Thanks for suggestions!

BR,
Jeff (Jiufu Guo)

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

[Richard Biener]

On Tue, 29 Aug 2023, Jiufu Guo wrote:

> 
> Hi All!
> 
> "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111166
> ...
> >
> >
> > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so
> > we can hardly fix it there.  Only a later pass could figure each of the
> > insns fully define the reg.
> >
> > Jiufu Guo is working to improve what we choose for DECL_RTL, but for
> > incoming params / outgoing return.  This is a case where we could,
> > with -fno-tree-vectorize, improve DECL_RTL for an automatic var and
> > choose not TImode but something like a (concat:TI reg:DI reg:DI).
> 
> Here is the patch about improving the parameters and returns in
> registers.
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628213.html
> 
> I have a question about how to bind an RTL to a TREE expression.
> In this patch, a map TREE->RTL is used. But it would be better if
> there was a faster way.
> 
> We have DECL_RTL/INCOMING_RTL, but they can only be bound to
> DECL(or PARM). In the above patch, the TREE can be an EXPR
> (e.g. COMPONENT_REF/ARRAY_REF).
> 
> Is there a way to achieve this? Thanks for suggestions!

No, but we don't need to bind RTL to COMPONENT_REF and friends,
what we want to change is the DECL_RTL of the underlying DECL.

Richard.

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

[Jiufu Guo]

Hi Richard,

Thanks a lot for your quick reply!

Richard Biener <rguenther@suse.de> writes:

> On Tue, 29 Aug 2023, Jiufu Guo wrote:
>
>> 
>> Hi All!
>> 
>> "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111166
>> ...
>> >
>> >
>> > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so
>> > we can hardly fix it there.  Only a later pass could figure each of the
>> > insns fully define the reg.
>> >
>> > Jiufu Guo is working to improve what we choose for DECL_RTL, but for
>> > incoming params / outgoing return.  This is a case where we could,
>> > with -fno-tree-vectorize, improve DECL_RTL for an automatic var and
>> > choose not TImode but something like a (concat:TI reg:DI reg:DI).
>> 
>> Here is the patch about improving the parameters and returns in
>> registers.
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628213.html
>> 
>> I have a question about how to bind an RTL to a TREE expression.
>> In this patch, a map TREE->RTL is used. But it would be better if
>> there was a faster way.
>> 
>> We have DECL_RTL/INCOMING_RTL, but they can only be bound to
>> DECL(or PARM). In the above patch, the TREE can be an EXPR
>> (e.g. COMPONENT_REF/ARRAY_REF).
>> 
>> Is there a way to achieve this? Thanks for suggestions!
>
> No, but we don't need to bind RTL to COMPONENT_REF and friends,
> what we want to change is the DECL_RTL of the underlying DECL.

In the above patch, the scalarized rtx for the access of the
parameter/returns are computed at the time when parameters
are set up.  And record "scalarized rtx" and "access expression".
When expanding an expression, the patch queries the scalarized rtx.

+  rtx x = get_scalar_rtx_for_aggregate_expr (exp);
+  if (x)
+    return x;

I'm reading "don't need to bind RTL to COMPONENT_REF and friends"
and "change is the DECL_RTL of the underlying DECL."
This may be doable. The method would be:
1. When the incoming/outgoing registers are determined, we can
  check if the parameter/return can be scalarized, **then bind
  the registers to DECL_RTL of the parm/ret**.
2. When expanding the expression (e.g. COMPONENT_REF), compute the
  scalarized rtx from DECL_RTL of the param/return.
  In expand_expr_real_1:
  case COMPONENT_REF: ... case ARRAY_REF: if base is parm...

Is my understanding correct?

BR,
Jeff (Jiufu Guo)

>
> Richard.

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

[Richard Biener]

On Tue, 29 Aug 2023, Jiufu Guo wrote:

> 
> Hi Richard,
> 
> Thanks a lot for your quick reply!
> 
> Richard Biener <rguenther@suse.de> writes:
> 
> > On Tue, 29 Aug 2023, Jiufu Guo wrote:
> >
> >> 
> >> Hi All!
> >> 
> >> "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
> >> 
> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111166
> >> ...
> >> >
> >> >
> >> > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so
> >> > we can hardly fix it there.  Only a later pass could figure each of the
> >> > insns fully define the reg.
> >> >
> >> > Jiufu Guo is working to improve what we choose for DECL_RTL, but for
> >> > incoming params / outgoing return.  This is a case where we could,
> >> > with -fno-tree-vectorize, improve DECL_RTL for an automatic var and
> >> > choose not TImode but something like a (concat:TI reg:DI reg:DI).
> >> 
> >> Here is the patch about improving the parameters and returns in
> >> registers.
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628213.html
> >> 
> >> I have a question about how to bind an RTL to a TREE expression.
> >> In this patch, a map TREE->RTL is used. But it would be better if
> >> there was a faster way.
> >> 
> >> We have DECL_RTL/INCOMING_RTL, but they can only be bound to
> >> DECL(or PARM). In the above patch, the TREE can be an EXPR
> >> (e.g. COMPONENT_REF/ARRAY_REF).
> >> 
> >> Is there a way to achieve this? Thanks for suggestions!
> >
> > No, but we don't need to bind RTL to COMPONENT_REF and friends,
> > what we want to change is the DECL_RTL of the underlying DECL.
> 
> In the above patch, the scalarized rtx for the access of the
> parameter/returns are computed at the time when parameters
> are set up.  And record "scalarized rtx" and "access expression".
> When expanding an expression, the patch queries the scalarized rtx.
> 
> +  rtx x = get_scalar_rtx_for_aggregate_expr (exp);
> +  if (x)
> +    return x;
> 
> I'm reading "don't need to bind RTL to COMPONENT_REF and friends"
> and "change is the DECL_RTL of the underlying DECL."
> This may be doable. The method would be:
> 1. When the incoming/outgoing registers are determined, we can
>   check if the parameter/return can be scalarized, **then bind
>   the registers to DECL_RTL of the parm/ret**.
> 2. When expanding the expression (e.g. COMPONENT_REF), compute the
>   scalarized rtx from DECL_RTL of the param/return.
>   In expand_expr_real_1:
>   case COMPONENT_REF: ... case ARRAY_REF: if base is parm...
> 
> Is my understanding correct?

Yes, that's how it works today.  The target computes DECL_RTL
for the parameter (could be a BLKmode memory), expansion
of references first expands the base and gets DECL_RTL
and then extracts the piece as analyzed via extract_bit_field
or more direct means.

As said in the review attempt sent out just now the complication
is allowing more "complex" DECL_RTL, say a set of possibly
different sized pseudos rather than a single pseudo or MEM.
There's support for CONCAT already (for _Complex), some
rough support for PARALLEL (not sure what it actually supports).

Richard.

> BR,
> Jeff (Jiufu Guo)
> 
> >
> > Richard.
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Re: Bind RTL to a TREE expr (Re: [Bug target/111166])

[Jiufu Guo]

Hi Richard,

Thanks a lot for your great comments!

Richard Biener <rguenther@suse.de> writes:

> On Tue, 29 Aug 2023, Jiufu Guo wrote:
>
>> 
>> Hi Richard,
>> 
>> Thanks a lot for your quick reply!
>> 
>> Richard Biener <rguenther@suse.de> writes:
>> 
>> > On Tue, 29 Aug 2023, Jiufu Guo wrote:
>> >
>> >> 
>> >> Hi All!
>> >> 
>> >> "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
>> >> 
>> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111166
>> >> ...
>> >> >
>> >> >
>> >> > At RTL expansion time we store to D.2865 where it's DECL_RTL is r82:TI so
>> >> > we can hardly fix it there.  Only a later pass could figure each of the
>> >> > insns fully define the reg.
>> >> >
>> >> > Jiufu Guo is working to improve what we choose for DECL_RTL, but for
>> >> > incoming params / outgoing return.  This is a case where we could,
>> >> > with -fno-tree-vectorize, improve DECL_RTL for an automatic var and
>> >> > choose not TImode but something like a (concat:TI reg:DI reg:DI).
>> >> 
>> >> Here is the patch about improving the parameters and returns in
>> >> registers.
>> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628213.html
>> >> 
>> >> I have a question about how to bind an RTL to a TREE expression.
>> >> In this patch, a map TREE->RTL is used. But it would be better if
>> >> there was a faster way.
>> >> 
>> >> We have DECL_RTL/INCOMING_RTL, but they can only be bound to
>> >> DECL(or PARM). In the above patch, the TREE can be an EXPR
>> >> (e.g. COMPONENT_REF/ARRAY_REF).
>> >> 
>> >> Is there a way to achieve this? Thanks for suggestions!
>> >
>> > No, but we don't need to bind RTL to COMPONENT_REF and friends,
>> > what we want to change is the DECL_RTL of the underlying DECL.
>> 
>> In the above patch, the scalarized rtx for the access of the
>> parameter/returns are computed at the time when parameters
>> are set up.  And record "scalarized rtx" and "access expression".
>> When expanding an expression, the patch queries the scalarized rtx.
>> 
>> +  rtx x = get_scalar_rtx_for_aggregate_expr (exp);
>> +  if (x)
>> +    return x;
>> 
>> I'm reading "don't need to bind RTL to COMPONENT_REF and friends"
>> and "change is the DECL_RTL of the underlying DECL."
>> This may be doable. The method would be:
>> 1. When the incoming/outgoing registers are determined, we can
>>   check if the parameter/return can be scalarized, **then bind
>>   the registers to DECL_RTL of the parm/ret**.
>> 2. When expanding the expression (e.g. COMPONENT_REF), compute the
>>   scalarized rtx from DECL_RTL of the param/return.
>>   In expand_expr_real_1:
>>   case COMPONENT_REF: ... case ARRAY_REF: if base is parm...
>> 
>> Is my understanding correct?
>
> Yes, that's how it works today.  The target computes DECL_RTL
> for the parameter (could be a BLKmode memory), expansion
> of references first expands the base and gets DECL_RTL
> and then extracts the piece as analyzed via extract_bit_field
> or more direct means.
I see.
>
> As said in the review attempt sent out just now the complication
> is allowing more "complex" DECL_RTL, say a set of possibly
> different sized pseudos rather than a single pseudo or MEM.

Right.  It seems PARALLEL can used for this purpose.
It can gather some pseudos with same/different sizes.

> There's support for CONCAT already (for _Complex), some
> rough support for PARALLEL (not sure what it actually supports).

"PARALLEL" is already used for incoming registers and return
registers.  So, it was also used in the light-sra patch.

BR,
Jeff (Jiufu Guo)

>
> Richard.
>
>> BR,
>> Jeff (Jiufu Guo)
>> 
>> >
>> > Richard.
>>