https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder if it makes sense for a production compiler to do this kind of
transformation. When presented with a program representation as SSA
on a CFG such transform would be quite ad-hoc or rather translating the
SSA + CFG representation into something a lot more high-level. On that
high-level it would indeed be kind of a liveness analysis and dead code
removal by means of iteration domain adjustments.
I wonder whether the polyhedral representation that -floop-nest-optimize
uses provides any advantage here (we certainly do not transfer knowledge
that the polyhedral represents all uses of a specific array and thus
unneeded computes can be eliminated - but if we did, would it make such
transforms automagically by simply pruning the polyhedral?)
In GCC the closest "high-level" representation we try to build is the
RDG loop-distribution builds, but obviously that doesn't even cover
the iteration domain.
As said, we're still missing a classical loop fusion transform - such
transform would benefit from a better "high-level" representation of
("simple") "loops" as well (and ideally fusion would work in concert
with distribution, not as separate passes). When we then have such
then pruning iteration domains from liveness analysis can be implemented
in such a framework (and liveness analysis should work on that high-level
representation). Alternatively loop splitting sounds like a transform
this could piggy-back on (given liveness analysis is done), split the
domain and elide one of the loops as dead.
I would advise against trying to invent a new pass just for this particular
transform.
