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). > Or do you want me to try that right away? No, I think at this point we want to see actual failures so we understand the failure modes better. Richard. > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
