Hi Richard,
Thanks a lot for your great comments! Richard Biener <rguent...@suse.de> writes: > 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. 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. >>
