This is an archive of the discontinued LLVM Phabricator instance.

[NFC] [LoopDeletion] Move ICmpInst handling to getValueOnFirstIteration()
ClosedPublic

Authored by dmakogon on Aug 31 2021, 2:31 AM.

Details

Summary

As noticed in https://reviews.llvm.org/D105688, it would be great to move handling of ICmpInst which was in canProveExitOnFirstIteration() to getValueOnFirstIteration()

Diff Detail

Event Timeline

dmakogon requested review of this revision.Aug 31 2021, 2:31 AM
dmakogon created this revision.
dmakogon created this object with visibility "dmakogon (Dmitry Makogon)".
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2021, 2:31 AM
dmakogon edited the summary of this revision. (Show Details)Sep 2 2021, 3:21 AM
dmakogon changed the visibility from "dmakogon (Dmitry Makogon)" to "Public (No Login Required)".
reames accepted this revision.Sep 2 2021, 9:25 AM

LGTM

Though, I don't believe this is NFC. It would be stronger in the case such as:
%a = icmp ...
%b = icmp ...
%c = or i1 %a, %b
%d = icmp eq i1 %c, 1
br i1 %d....

This is non-canonical IR so this should be a rare pattern in practice, but I don't think this is actually NFC.

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

As a follow up, it looks like this test is now redundant for the new code structure. Only part I'm unsure of is the integer test, but I also don't understand why that's there at all.

This revision is now accepted and ready to land.Sep 2 2021, 9:25 AM
mkazantsev added inline comments.Sep 3 2021, 2:15 AM
llvm/lib/Transforms/Scalar/LoopDeletion.cpp
329

You're right, vector type should not pass the matcher. We'll remove it in a follow-up.

This revision was landed with ongoing or failed builds.Sep 3 2021, 4:36 AM
This revision was automatically updated to reflect the committed changes.