[PATCH] D32261: [LoopUnroll] Don't try to unroll non-rotated loops

[Davide Italiano via Phabricator via llvm-commits]

davide added a comment.



In https://reviews.llvm.org/D32261#732780, @Gerolf wrote:

> I don't know if this patch makes the situation better or worse. It seems to touch on the tip of an iceberg. The underlying problem is: What can or should happen when a loop is irreducible? It the answer is "don't unroll", then this is the fix your actually looking for. Obviously this loop is irreducible since it has a retreat edge from sink to body2, but body2 does not dominate sink. I'm also curious if this loop is in the source code already or if some pass in the compiler actually generated. FWIW, unless the compiler has a problem irreducible loops should be rare. And when the user writes an irreducible loop, I think it is OK when compiler optimizations turn conservative.
>
> -Gerolf


Unless I'm reading the test in the PR incorrectly (which I might) the input contains already the loop (and it's not generated by the compiler).
Please note that the testcase I hit internally and the PR reported upstream are both generated by a fuzzer, and looking at them they don't seem to resemble any kind of real code.
That said, I cannot make a call, but I'm under the impression that loops like this are infrequent enough that bailing out is not necessarily unreasonable. I consider not crashing (or ending up with a corrupt dominator) more important in this case, and in this sense, this patch is an improvement compared to what we have today. If we want to improve the algorithm later to handle more sophisticated latches/multiple latches, we might as well do later (and quite frankly, I wouldn't really go that route until we hit a case where this matters).
What do you think?


https://reviews.llvm.org/D32261