https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126103
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 9 Jul 2026, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126103 > > --- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > (In reply to Andrew Macleod from comment #8) > > > Wait, I'm a little confused... if the goal is to remove DOM, why are we > > adding changes to DOM which invalidates ranger caches so ranger gets the > > same thing while processing changes DOM performed? > > > > Shouldn't we be running ranger/VRP instead of DOM and then flagging things > > DOM gets that ranger didn't? Or am I missing something... > > The plan was to replace the DOM threader with an instance of the ranger > threader first, as DOM is a hodge podge of optimizations, some of which are > suitable to VRP and some of which aren’t. I think some belong in PRE or > elsewhere. > > So the idea was to assert the ranger can get everything DOM does from within > the hybrid threader in this release, and then move the DOM threader to a > ranger > threader in the next release, and whatever is left over in DOM can be done by > the relevant passes. Or so I thought... I’m open to other suggestions; I just > can’t do the legwork for the other bits of DOM. > > I’m just a bit queasy to remove everything at once. Any invalidating changes > and the like in theory will be short-lived, cause I don’t think we need them > going forward. > > I’m all ears, and open to suggestions :). I guess such transition plan is bound to fail since DOMs forward threader is inter-winded with its optimization. I would say the first goal would be to dis-entangle testcases for the forward threader from testcase for DOMs value-numbering. I'd expect we'll replace DOM with a non-iterating FRE plus a backward threader pass. We have NEXT_PASS (pass_thread_jumps, /*first=*/true); NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */); early and NEXT_PASS (pass_fre, false /* may_iterate */); /* After late FRE we rewrite no longer addressed locals into SSA form if possible. */ NEXT_PASS (pass_thread_jumps, /*first=*/false); NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */); late. That might suggest both could ideally be just NEXT_PASS (pass_fre, false /* may_iterate */); NEXT_PASS (pass_thread_jumps, ...); I'm not sure it makes sense to try to debug and resolve any intermediate state (but possibly disable threading in DOM and retain DOM in place of FRE). For the current early pass combo we might just see secondary threading effects with regard to copying limits applying again after simplifying threaded paths (we run too many threader passes anyway).
