On Tue, Jun 10, 2025 at 12:55:39PM +0200, Richard Biener wrote:
> Yes, it must (but we expand those separately, so we could tear down
> ranger then).
>
> So apart from ICEing I wonder how ranger (and it's cache) deals with
> basic blocks being added, edges vanishing (we kill off all abnormal
> edges - those ranger usually "stops" at, for correctness), edges
> being added (find_many_sub_basic_blocks), etc. - are we sure we
> get correct range answers when the cache was from a "different"
> CFG (the set of CFG manipulations are of course constrained, but
> this isn't very well documented and also not very well ordered/isolated)
Killing off all abnormal edges and find_many_sub_basic_blocks are both
after disabling ranger (note to self, I should remove the last hunk
in cfgexpand.cc in the incremental patch to introduce expand_remove_edge,
because exactly that case is the AB removal and there all bbs are guaranteed
to be BB_RTL and so no special casing is needed).
I'd hope that what we add as BB_RTL blocks doesn't contain anything
interesting from the ranger POV but I don't know the ranger cache/CFG walks
it does; so the tweaks I've done were just from the ICEs I saw.
There is one case which is possible, namely
maybe_cleanup_end_of_block from expand_gimple_cond can sometimes kill one
of the two edges after GIMPLE_COND; I've arranged EDGE_TRUE_VALUE or
EDGE_FALSE_VALUE flag to remain on the other edge, so in theory ranger
can deal with it during currently_expanding_to_rtl time, but I don't have
testcases for that, maybe it is mostly or purely theoretical, because we'd
better clean those up already during GIMPLE passes.
In theory we could defer the deletion of those and just push it into some
vector for later removal.
Jakub
