https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100221
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |12.0
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the reduced testcase the issue is simply that DSE doesn't walk across
multiple paths and we have
<bb 4> :
# .MEM_9 = VDEF <MEM_4>
g = &c;
a.1_2 = a;
if (a.1_2 != 0)
goto <bb 6>; [INV]
else
goto <bb 7>; [INV]
<bb 5> :
b = 0;
<bb 6> :
.MEM_5 = PHI <.MEM_9(4), .MEM_12(5)>
b.2_3 = b;
if (b.2_3 != 0)
goto <bb 5>; [INV]
else
goto <bb 7>; [INV]
<bb 7> :
.MEM_6 = PHI <.MEM_9(4), .MEM_5(6)>
g ={v} {CLOBBER};
return 0;
with the walking gathered the .MEM_5 and .MEM_6 defs when following the
.MEM_9 uses and
/* In addition to kills we can remove defs whose only use
is another def in defs. That can only ever be PHIs of which
we track two for simplicity reasons, the first and last in
{first,last}_phi_def (we fail for multiple PHIs anyways).
We can also ignore defs that feed only into
already visited PHIs. */
else if (single_imm_use (vdef, &use_p, &use_stmt)
&& (use_stmt == first_phi_def
|| use_stmt == last_phi_def
|| (gimple_code (use_stmt) == GIMPLE_PHI
&& bitmap_bit_p (visited,
SSA_NAME_VERSION
(PHI_RESULT (use_stmt))))))
defs.unordered_remove (i);
does not trigger to remove either PHI def from consideration (but in
principle we could elide .MEM_6 and continue processing .MEM_5 which
eventually will lead us to .MEM_6 anyway). I suppose the key would be
realizing that one of the PHI defs is a PHI argument of the PHI we can
postpone in this round.
