https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126103
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #7)
> Created attachment 64970 [details]
> untested patch invalidating gori exports as a proof of concept
>
> The single predecessor to the path entry is:
>
> (gdb) p ::debug(bb)
> <bb 343> [local count: 9493345]:
> _406 = _890;
> if (_890 == 0B)
> goto <bb 349>; [30.00%]
> else
> goto <bb 367>; [70.00%]
>
> but even a simple range_on_edge(_890, e=343->367) returns VARYING. This is
> because we have already visited BB343 in its pre propagated form, and gori's
> exports have already been baked:
>
> bitmap
> gori_map::exports (basic_block bb)
> {
> if (bb->index >= (signed int)m_outgoing.length () ||
> !m_outgoing[bb->index])
> calculate_gori (bb);
> return m_outgoing[bb->index];
> }
>
> Since m_outgoing[] is filled, we don't call calculate_gori().
>
> The attached patch (ahem, hack), invalidates the gori exports for blocks
> where we have modified conditionals. This causes gori to recalculate, and
> brings down the number of discrepancies as mentioned in PR125986 from 92 to
> 35.
>
> This is just an idea, have some way of nuking the cache or the gori
> exports if we’re modifying a statement that can potentially alter the
> outgoing ranges from a block. I'm sure y'all can think of something more
> elegant ;-).
Wait, I'm a little confused... if the goal is to remove DOM, why are we adding
changes to DOM which invalidates ranger caches so ranger gets the same thing
while processing changes DOM performed?
Shouldn't we be running ranger/VRP instead of DOM and then flagging things DOM
gets that ranger didn't? Or am I missing something...
