https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #5 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > No, I think the issue is that ESRA leaves e.f0 alone: > > e$f3_7 = e.f3; > e$f0$f4_8 = e.f0.f4; > _1 = e$f0$f4_8; > _2 = (unsigned char) _1; > e$f3_9 = _2; > e.f0 = g_50; > e$f3_10 = MEM <uint8_t> [(struct S1 *)&g_50]; > e$f0$f4_11 = MEM <int32_t> [(struct S1 *)&g_50 + 24B]; > MEM <uint8_t> [(union U8 *)&e] = e$f3_10; > MEM <int32_t> [(union U8 *)&e + 24B] = e$f0$f4_11; > g_16 = e.f0; > > it looks like it materializes the e.f0 = g_15 copy but fails to elide that > (maybe assuming sth else will?)? And then for some reason the final > g_16 = e.f90 copy isn't replaced?! > > So somehow SRAs heuristics go off. > > Martin? I am afraid this is just another example of what flow-insensitive SRA cannot optimize well. I'll keep it in the list of testcases to hopefully one day improve on when we make it flow sensitive.
