On 6/10/25 08:21, Richard Biener wrote:
On Tue, 10 Jun 2025, Jakub Jelinek wrote:
On Tue, Jun 10, 2025 at 01:05:51PM +0200, Richard Biener wrote:
With your experiment of computing ranges for everything we're good
from the ICE point-of-view. I think there's nothing we can do to
reassure us of correctness, so I'd take Andrews advice here (aka,
go ahead). The only thing we can do in theory is instrument each
SSA def like with
Ok, will merge the incremental patch into the original and commit,
if things go wrong we can always revert (if you're ok with that).
Yes, that works for me.
And perhaps one possible way to deal with possible problems would be
to extend what the patch does further (currently it mainly defers
converting BBs from !BB_RTL to BB_RTL by remembering in a vector
new BB_HEAD/BB_END). Taking it further could mean perhaps in another
vector remember deferred operations, remove some particular edge,
create new basic block and emit some RTL instructions into it, etc.,
whatever are the needed operations.
So we could have deferred_remove_edge, deferred_create_bb etc. APIs
and then we'd just disable ranger, then rtl_register_cfg_hooks ();
(move it from where it is done right now) change BBs
expand_gimple_basic_block touched and then replay all the deferred
actions.
I think pushing RTL on the edges is fine, I think ranger shouldn't
be trying to walk GIMPLE stmts queued on edges but not committed yet
(and so shouldn't walk the RTL on the edges either).
It only walks SSA use->def chains, I don't think it ever walks
"all stmts" of a block (or edge as you say).
yes, Ranger will just walk the use-def chains, and never looks at
anything queued on an edge or elsewhere.
Andrew
