https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126103
--- Comment #11 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to [email protected] from comment #10) > 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). That makes sense, though it’s above my level of expertise, if I still have any ;-), and time commitments, but in the meantime I’m happy to chug away at flagging any missing optimizations in either ranger or the path ranger. I have seen a handful of places where we’re missing things that are not related to IL changes (relations, propagation of inequality among pointers, interactions between PHIs and ranges within a path, etc). Are you suggesting we disable threading in DOM, leave DOM in place originally, and follow it up with a backwards threader? That seems quite aggressive, at least it requires time commitment to follow through on anything that falls through the cracks initially.
