On 6/10/25 07:10, Jakub Jelinek wrote:
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.
As long as the SSA use-def chains don't lead to one of those blocks, I
don't anticipate any problems.. the cache doesn't look into blocks, just
manages a range-on-entry which is propagated via edges.. as long as
gimple_outgoing_range_stmt_p() works for the RTL blocks and indicates
there is no outgoing stmt, propagation will merely bypass the block
because it doesnt do anything interesting.
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.
Yes, there are places , particularly fold_using_range in
gimple-range-fold.cc, which expects there to be 2 edges to a GCOND
stmt. it always expects 2 successors. There are not many places like
that, many simply look at the specified edge of a gcond... but the few
there are could also be adjusted pretty easily to check if the edge is
there before doing anything...
Andrew
