On Tue, 29 Aug 2023, Jiufu Guo wrote: > > Hi Richard, > > Thanks a lot for your quick reply! > > Richard Biener <rguent...@suse.de> writes: > > > On Tue, 29 Aug 2023, Jiufu Guo wrote: > > > >> > >> Hi All! > >> > >> "rguenth at gcc dot gnu.org" <gcc-bugzi...@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 <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
