On Mon, Jun 22, 2026 at 8:53 AM Andrea Pinski <[email protected]> wrote: > > On Mon, Jun 22, 2026 at 8:03 AM Aldy Hernandez <[email protected]> wrote: > > > > 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. > > I think that is a good idea.
Just as an FYI, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126010 as the meta bug tracking issues which are only handled by DOM. I filed a few issues already; in fact it looks like at least one of them I was already started to handle (PR 102138) and I had posted a RFC for it just last week: https://gcc.gnu.org/pipermail/gcc-patches/2026-June/721701.html I will be finishing it up hopefully next week (including the go front-end issue). Thanks, Andrea > > Thanks, > Andrea > > > > > Aldy
