[PATCH] D22952: [LoopVectorize] Detect loops in the innermost loop before creating InnerLoopVectorizer

[Adam Nemet via llvm-commits]

anemet added a comment.

In https://reviews.llvm.org/D22952#503039, @mkuper wrote:

> In https://reviews.llvm.org/D22952#502880, @anemet wrote:
>
> > Where this check should be is related to PR28374.  I think it should be checked when we initially gather the inner most loops in addInnerLoop.
>
>
> I'm not sure. I mean, both ways make sense, but the way I see it is the inner-most "loop", in the sense that there are no loops (as opposed to cycles) living inside it. So adding it, and then performing a legality check makes sense to me. 
>  What's the motivation for doing it in addInnerLoop? I don't see why that would improve reporting, and I think it'd be nicer to leave addInnerLoop straight-forward, and keep all of the negative conditions in the legality check.


I guess it all depends on whether you think these checks are similar or not.  I don't really see the difference between loops and cycles.  For example, when I look at the testcase in C, I essentially see two nested loops even though the inner one is a bit weird (I guess it's multi-entry).  I am not sure that it make sense to differentiate the two to the user either.

Thus I'd like to have a single place where we check for the inner-most loop property (with LoopInfo and beyond) and where we properly report back to the user.  This is currently addInnerLoop.  (The other place is dead before the patch, AFAICT.)


https://reviews.llvm.org/D22952