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 :).
