On Tue, 16 Dec 2025, Avinash Jayakar wrote: > Hi, > > I was looking into the polyhedral optimizations that are done in GCC > using the graphite pass. Just had a few queries as I was looking into > PR14741 on its current state: > > 1. Are there any resources I could look into to see how it performs > compared to the source to source optimizer Pluto or LLVM's polly? And > any plans to improve the current optimizations that are done in > graphite?
IIRC Michael Matz last worked a bit on graphite, not sure if any of that work was upstreamed. The reason graphite is still there is that at least leveraging dependence analysis might be worthwhile, otherwise it's unmaintained. > 2. I see that using "-O2 -fgraphite -floop-block -fdump-tree-all", the > graphite pass is actually placed a bit deeper in the pipeline. And I > observed that it hinders ability to do polyhedral transformations, > since it creates complex loop dependencies after loop invariant motion > and partial redundancy elimination. > Any reason as to why it is placed so deep in the pipeline? Because > according to the tools I have seen, it would be beneficial to perform > polyhedral analysis/transformations closer to source. It's been always in the place it is now. > 3. Is graphite under active development? Would it be beneficial to > implement polyhedral transforms closer to the source level (right after > gimplification)? No, it's not under active development. As to the second question - I don't know? Do you? I'd suggest to simply try. > Also I think it would be useful to have some kind of metadata/pragma > for the scops, where a programmer familiar with polyhedral schedules > could specify a custom transformation like blocking/interchange. > Something like > > #pragma beginscop > #pragma transform (i, j, k) -> (j / N_C, k / K_C, i / M_C, j / N_R, i / > M_R, k mod K_C, j mod N_R, i mod M_R) > for loop... > > #pragma endscop Huh. I think there's OpenMP annotations for such things, so I'd suggest to leverage those annotations, possibly with a -fopenmp-hllt (high-level-loop-transforms). Richard. > Please let me know your thoughts/comments on this. > > Thanks and regards, > Avinash Jayakar > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
