This is an archive of the discontinued LLVM Phabricator instance.

[LV] Don't panic when encountering the IV of an outer loop.
ClosedPublic

Authored by mkuper on Jan 9 2017, 3:10 PM.

Details

Summary

Bail out instead of asserting when we encounter this situation - which can actually happen.
Note that the assert I removed doesn't actually get hit (because it checks the wrong condition), but we assert a bit further down the line.

The reason the test uses the new PM is that the "bad" phi - incidentally - gets cleaned up by LoopSimplify. But LICM can create this kind of phi and preserve loop simplify form, so the cleanup has no chance to run.

This fixes PR31190.
We may want to solve this in a less conservative manner, since this phi is actually uniform within the inner loop (or we may want LICM to output a cleaner promotion to begin with), but I'd rather fix the crash for now.

Diff Detail

Event Timeline

mkuper updated this revision to Diff 83714.Jan 9 2017, 3:10 PM
mkuper retitled this revision from to [LV] Don't panic when encountering the IV of an outer loop..
mkuper updated this object.
mkuper added reviewers: delena, mssimpso, sbaranga.
mkuper added subscribers: llvm-commits, davide.
sanjoy added a subscriber: sanjoy.Jan 9 2017, 3:31 PM

I can't really review the code; but, did you consider writing the test case in C++ (inside unittests/)? Relying on LICM to create just the right preconditions seems somewhat fragile (that is, it is possible that a future change to LICM will make this test a no-op).

mkuper added a comment.Jan 9 2017, 3:38 PM

I can't really review the code; but, did you consider writing the test case in C++ (inside unittests/)? Relying on LICM to create just the right preconditions seems somewhat fragile (that is, it is possible that a future change to LICM will make this test a no-op).

I agree, it's fragile, but I think it would be really nice to keep this kind of test-case in IR, for the sake of maintainability.
This whole "LV requires LCSSA and LoopSimplify" issue will need to be solved as part of the move to the new pass manager. I'd prefer to leave a FIXME in the test, and set myself a reminder to actually go and fix it in a couple of months. :-)

(Actually, maybe I can avoid this whole thing by running the test with the new pass manager instead of the old one! I'll give it a shot.)

mkuper updated this revision to Diff 83726.Jan 9 2017, 3:50 PM
mkuper updated this object.

Test no longer relies on LICM. Thanks, Sanjoy.

delena added inline comments.Jan 9 2017, 11:15 PM
test/Transforms/LoopVectorize/pr31190.ll
8

Can you add the source code to the comments? You try to vectorize the "for.body3" loop, right? What PHI belongs to the outer loop?

mkuper added inline comments.Jan 10 2017, 12:00 AM
test/Transforms/LoopVectorize/pr31190.ll
8

Yes, it's trying to vectorize the inner loop (for.body3).
The problematic PHI is:
%0 = phi i32 [ undef, %for.cond1.preheader ], [ %inc54, %for.body3 ]

This phi is in the inner loop, but %inc54 is an IV phi in the outer loop:
%inc54 = phi i32 [ %inc5, %for.cond1.for.inc4_crit_edge ], [ %c.promoted, %entry ]
So SCEV recognizes %0 as an AddRec, but with respect to the outer loop.

I'll add the above explanation in a comment.
Not sure about the source, though - the IR was, I think, hand-reduced by @davide from the source in PR31190, so I'm not sure having the "original" source he makes a lot of sense.

delena edited edge metadata.Jan 10 2017, 12:27 AM

LGTM for this patch. You can open a PR, since this loop should be vectorized and the PHI is uniform.
Please add a comment, at least to this test, pointing to the uniform PHI node.

mssimpso added inline comments.Jan 10 2017, 8:24 AM
test/Transforms/LoopVectorize/pr31190.ll
8

So SCEV recognizes %0 as an AddRec, but with respect to the outer loop.

I haven't tried this so I'm not really sure, but would SE->getSCEVAtScope(Phi, TheLoop) be useful here?

mkuper added inline comments.Jan 10 2017, 10:59 AM
test/Transforms/LoopVectorize/pr31190.ll
8

I think it will work, but that doesn't really help. We'll just end up with an unidentified phi, so we won't vectorize regardless.
I'd prefer to leave this explicit, but I don't mind trying getSCEVatScope if you think that's better.

mssimpso added inline comments.Jan 10 2017, 11:07 AM
test/Transforms/LoopVectorize/pr31190.ll
8

Ah, yes you're right, the phi would just be unknown. Leaving the check explicit is probably better. This looks good to me!

This revision was automatically updated to reflect the committed changes.