Jeffrey Law <[email protected]> writes: > On 6/18/2026 1:21 AM, Aldy Hernandez wrote: >> Andrew MacLeod <[email protected]> writes: >> >>> This patch provides the initial implementation to track points-to >>> information in prange. >> Very cool. This was one of two things I really wished I could've gotten >> done before stepping aside. I'm glad it didn't fall through the cracks. >> >> And the second one is... getting rid of DOM. With prange having >> points-to info, ISTM that all that's standing in the way of getting rid >> of DOM is doing the hard work of finding what the side tables are >> getting that ranger doesn't. It theory it should be nothing; in >> practice it's always complicated :). >> >> Last time I did an audit of what the forward threader was getting I >> think it was some pointer equivalency stuff, as I think we were even >> getting all the floating point stuff with frange. >> >> That is, if y'all still agree that removing the forward threader along >> with DOM is the way to go. I don't know if anything has changed. >> >> Maybe after summer is over, and the kids are back in school, I can take >> a stab at auditing what remains to be done, to at least get an idea. >> >> Again, thanks for your hard work on this. Sorry I haven't been able to >> help much. > Dropping DOM's threading as well as DOM itself should still be the > plan of record. As you note, the actual mechanics of doing that > without regressing is complicated. > > What I expected us to find in that effort was that things like > const/copy propagation and redundant expression elimination are better > handled by other passes and can largely be dropped. The path > specific optimizations are probably within reach of ranger now. What > would be left would be the backwards propagation bits. At least that's > the way it seems to me without actually instrumenting DOM to see > what's left that's triggering in practice.
I was thinking I could start by instrumenting the hybrid threader (DOM threader with ranger as a helper when the DOM tables fail), to see what ranger is unable to get, and open a PR for each missing optimization. Once we get those resolved, perhaps we could disable the DOM tables for the threader in this cycle, and in the next cycle replace it with a post-DOM backwards threader instance. That way we get a cycle to clean anything up. BTW, a preliminary run across the .ii files in a bootstrap only shows 3 missing optimizations for prange. So at least for prange, I think we're in pretty good shape. How does that sound? I.e. let's tackle the hybrid threader first, and then the const/copy prop and CSE stuff later :). Sorry, I'm just trying to slim things down so that I can contribute in some way, without tackling something impossible for me right now. Aldy
