On Mon, 31 Mar 2025, Martin Jambor wrote: > Hi, > > during analysis of PR 118924 it was discussed that total scalarization > invents access paths (strings of COMPONENT_REFs and possibly even > ARRAY_REFs) which did not exist in the program before which can have > unintended effects on subsequent AA queries. Although not doing that > does not mean that SRA cannot create such situations (see the bug for > more info), it has been agreed that not doing this is generally better. > This patch therfore makes SRA fall back on creating simple MEM_REFs when > accessing components of an aggregate corresponding to what a SRA > variable now represents. > > Bootstrapped on x86_64-linux and Aarch64-linux. OK for master and then > for all active release branches?
OK with me. Thanks, Richard. > Thanks, > > Martin > > > gcc/ChangeLog: > > 2025-03-26 Martin Jambor <mjam...@suse.cz> > > PR tree-optimization/118924 > * tree-sra.cc (create_total_scalarization_access): Set > grp_same_access_path flag to zero. > --- > gcc/tree-sra.cc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc > index 22d5d1ce999..8014bf1e6b4 100644 > --- a/gcc/tree-sra.cc > +++ b/gcc/tree-sra.cc > @@ -3463,7 +3463,7 @@ create_total_scalarization_access (struct access > *parent, HOST_WIDE_INT pos, > access->grp_write = parent->grp_write; > access->grp_total_scalarization = 1; > access->grp_hint = 1; > - access->grp_same_access_path = path_comparable_for_same_access (expr); > + access->grp_same_access_path = 0; > access->reverse = reverse_storage_order_for_component_p (expr); > > access->next_sibling = next_sibling; > -- 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)
