https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126103
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- Created attachment 64970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64970&action=edit 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 ;-).
