https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122663
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jamborm at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so all this purge_all_uses stuff seems awkward from a design perspective.
As I understand we'll have defs formerly feeding the return stmt that will
end up with no uses and running simple_dce_from_worklist starting from those
would a) produce debug stmts in correct order, b) not suffer from this issue.
Now - we're doing all this IL modification from within
redirect_call_stmt_to_callee called by inline-transform which IMO makes it
even more suspicious. I think it would make more sense to seed a
simple_dce_from_worklist when modifying the return stmt (this seems to already
have happened here).
purge_all_uses seems to possibly remove defs for stmts that might have uses
from other paths, like
_1 = foo ();
_2 = bar ();
return _1 + 2;
in case we remove the return value here we'd remove the addition stmt
before then still visiting it when iterating over the other call LHS
uses.
If we really need to work from the calls LHS then purge_all_uses should
do the imm-use walk to determine the has_zero_use 'leaf' and only prune
stmts from there, in the simple_dce_from_worklist way.
I have a patch fixing the testcase but possibly breaking the path where
we have a "global" killed_ssas. That
global killed-ssas could possibly be replaced by a 'unused-ssas' to guide
the simple-dce-from-worklist. The only user besides edge redirection
and final cleanup by releasing SSA names is remap_ssa_name which seems
to adjust debug stmt remapping beavior.
