Richard Guenther wrote: >> If this is not clear, I can write some pseudo-code to clarify :-). > > Can't we use graphite to re-roll loops? That is, compress the > polyhedron by introducing a new parameter? But maybe I am > not good at guessing what your initial bloat issue looks like. > > The reason I'm asking is that there is enough code out in the > wild that has loops with manually unrolled bodies - I have seen > up to 16 times here. >
I agree that the conditions I propose are not as reliable as unrolling and checking if it helps. At some point, this kind of sandboxing of the IR to explore a tree of optimizations would be interesting... except for compilation time and memory usage :-( Great for iterative and machine learning optimization anyway. Regarding your rerolling question, it is currently not known. There is indeed a nice parallel between rerolling and the code generation algorithms in CLooG. But this is only for rerolling right after unrolling. The real problem is rerolling after a sequence of optimizations that took advantage of prior unrolling. In this case, we have an algorithm equivalence problem, very general and very nasty. Polyhedral approaches do help but so far did not do much more than very theoretical papers and toy prototypes (I can give references if you are interested). Clearly, it would be nice to have a rerolling pass, it would also help the intra-block vectorization (there are specific papers on this, and preliminary support in the vectorizer), but it is not something people understand well. We'll wait a little, but more feedback on conditions to stricten the application of the early unrolling pass will be helpful, then one of the Graphite developers may gets his or her hand dirty on it. Albert
