https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109667
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |12.3
CC| |jamborm at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-04-28
Priority|P3 |P2
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We end up with
void assign (struct i256 * v, long int z)
{
struct i256 r;
<bb 2> [local count: 536870913]:
MEM <char[24]> [(struct i256 *)&r + 8B] = {};
r.v[0] = z_8(D);
*v_5(D) = r;
r ={v} {CLOBBER(eol)};
return;
}
and I think the issue is that DSE trims the zero-initialization. -fno-tree-dse
fixes it - not doing DSE enables SRA:
r = {};
r.v[0] = z_8(D);
*v_5(D) = r;
r ={v} {CLOBBER(eol)};
can SRA while
MEM <char[24]> [(struct i256 *)&r + 8B] = {};
r.v[0] = z_8(D);
*v_5(D) = r;
r ={v} {CLOBBER(eol)};
FAILs:
Candidate (2756): r
Created a replacement for r offset: 0, size: 64: r$v$0D.2766
...
MEM <char[24]> [(struct i256 *)&r + 8B] = {};
r$v$0_13 = z_8(D);
r.v[0] = r$v$0_13;
*v_5(D) = r;
that was pointless - compared to
Candidate (2756): r
Will attempt to totally scalarize r (UID: 2756):
Created a replacement for r offset: 0, size: 64: r$v$0D.2766
Created a replacement for r offset: 64, size: 64: r$v$1D.2767
Created a replacement for r offset: 128, size: 64: r$v$2D.2768
Created a replacement for r offset: 192, size: 64: r$v$3D.2769
...
r$v$0_13 = 0;
r$v$1_2 = 0;
r$v$2_1 = 0;
r$v$3_11 = 0;
r$v$0_10 = z_8(D);
v_5(D)->v[0] = r$v$0_10;
v_5(D)->v[1] = r$v$1_2;
v_5(D)->v[2] = r$v$2_1;
v_5(D)->v[3] = r$v$3_11;
possibly SRA is confused by the char[24] type. It's going to be difficult
to do better though.
