https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126103
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #5)
> This looks like DOM changed the IL from under the root ranger. In the dom2
> dump we see:
>
> ==== ASGN _406 = _890
> Optimizing statement if (_406 == 0B)
> Replaced '_406' with variable '_890'
> Matching expression match.pd:3125, gimple-match-3.cc:104
> Matching expression match.pd:3129, gimple-match-6.cc:89
> Matching expression match.pd:3139, gimple-match-10.cc:86
> Matching expression match.pd:3145, gimple-match-9.cc:93
> Matching expression match.pd:195, gimple-match-6.cc:22
>
> Visiting conditional with predicate: if (_890 == 0B)
>
> The original conditional was _406 == 0, which DOM copy propagated with _890,
> and then later tried to ask ranger to resolve the _890.
>
> I wonder if we need a mechanism to invalidate ranger/gori’s knowledge of a
> block when we alter a statement in DOM.
DOM should only ever change the "current" stmt, and do range queries on the
current stmt where all upthread (dominator-wise) stmts are already processed
by DOM. So I only see the possibility that ranger walks backedges to stmts
not yet visited?
