This is an archive of the discontinued LLVM Phabricator instance.

[LoopDeletion] Consider infinite loops alive, unless mustprogress.
ClosedPublic

Authored by fhahn on May 30 2021, 8:52 AM.

Details

Summary

The current loop or any of its sub-loops may be infinite. Unless the
function or the loops are marked as mustprogress, this in itself makes
the loop *not* dead.

This patch moves the logic to check whether the current loop is finite
or mustprogress to isLoopDead and also extends it to check the
sub-loops. This should fix PR50511.

Diff Detail

Event Timeline

fhahn created this revision.May 30 2021, 8:52 AM
fhahn requested review of this revision.May 30 2021, 8:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 30 2021, 8:52 AM
nikic added a comment.May 30 2021, 9:19 AM

This looks okay with one caveat: We could still have an irreducible inner cycle, which will not be represented in LoopInfo. Any thoughts on what to do about that?

llvm/lib/Transforms/Scalar/LoopDeletion.cpp
142

Just to double check, subloops also includes recursive subloops, right?

llvm/test/Transforms/LoopDeletion/noop-loops-with-subloops.ll
217

This is probably not checking what you want, because you also have the mustprogress function attribute, next to the loop metadata.

298

You probably meant to use %c3 here.

llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
339

This remark shouldn't be there anymore ... possibly matches a future remark?

fhahn updated this revision to Diff 348855.May 31 2021, 12:40 PM

Updated to visit all sub-loops, after adding additional tests in 5c9fe816e3b6. That commit should also addresses the other test-specific comments.

This looks okay with one caveat: We could still have an irreducible inner cycle, which will not be represented in LoopInfo. Any thoughts on what to do about that?

Ah yes, I forgot to mentioned that in the description. Irreducible cycles have never been handled properly in loop-deletion, so I think it would make sense to fix that separately. I don't think there's much we can do other than bailing out on functions that contain irreducible control-flow for now. To do that in loop passes we might need a better way to cache the result of the analysis.

fhahn marked 2 inline comments as done.May 31 2021, 12:44 PM
fhahn added inline comments.
llvm/lib/Transforms/Scalar/LoopDeletion.cpp
142

I initially thought that all cases should be covered by the tests, but we need to visit all sub-loops recursively. I updated the code. Relevant additional tests in 5c9fe816e3b6

llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
339

I think there's still a loop removed (L2), as the comment indicates.

nikic added a comment.May 31 2021, 1:04 PM

This looks okay with one caveat: We could still have an irreducible inner cycle, which will not be represented in LoopInfo. Any thoughts on what to do about that?

Ah yes, I forgot to mentioned that in the description. Irreducible cycles have never been handled properly in loop-deletion, so I think it would make sense to fix that separately. I don't think there's much we can do other than bailing out on functions that contain irreducible control-flow for now. To do that in loop passes we might need a better way to cache the result of the analysis.

Yes, I agree that this should be handled separately.

llvm/lib/Transforms/Scalar/LoopDeletion.cpp
118–122

Apart from FnMustProgress, aren't these checks redundant with the ones in the worklist loop?

llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
339

Oh right.

fhahn updated this revision to Diff 348924.Jun 1 2021, 3:40 AM

Simplify code: move checks into loop, remove lambda.

fhahn added inline comments.Jun 1 2021, 3:42 AM
llvm/lib/Transforms/Scalar/LoopDeletion.cpp
118–122

yes, the lambda is not really necessary any longer, I moved the checks in the loop directly.

nikic accepted this revision.Jun 1 2021, 3:45 AM

LGTM

This revision is now accepted and ready to land.Jun 1 2021, 3:45 AM