Page MenuHomePhabricator

[JumpThreading] In updatePredecessorProfileMetadata, stop searching predecessor when the current bb is an unreachable single bb loop
ClosedPublic

Authored by wmi on Jul 25 2019, 5:03 PM.

Details

Summary

updatePredecessorProfileMetadata in jumpthreading tries to find the first dominating predecessor block for a PHI value by searching upwards the predecessor block chain.

But jumpthreading may see some temporary IR state which contains unreachable bb not being cleaned up. If an unreachable single bb loop happens to be on the predecessor block chain, keeping following the predecessor block will run into an infinite loop.

The patch fixes it.

Diff Detail

Repository
rL LLVM

Event Timeline

wmi created this revision.Jul 25 2019, 5:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 25 2019, 5:03 PM
Herald added subscribers: jfb, hiraditya. · View Herald Transcript

Is there any reason to expect that unreachable loops have exactly one block?

wmi added a comment.Jul 25 2019, 7:15 PM

Is there any reason to expect that unreachable loops have exactly one block?

I was wrong. I thought getSinglePredecessor already handle the case but I didn't think it carefully enough. Thanks for catching it.

I update the patch to stop searching whenever unreachable code is seen, and update the test with unreachable multi-bbs loop case.

wmi updated this revision to Diff 211871.Jul 25 2019, 7:17 PM

Address Eli's comment.

Please rebase against trunk.

llvm/lib/Transforms/Scalar/JumpThreading.cpp
1214 ↗(On Diff #211871)

Calling getDomTree() here is expensive; it flushes all updates in the DomTreeUpdater.

wmi updated this revision to Diff 211978.Fri, Jul 26, 12:15 PM

Address Eli's comment.

This revision is now accepted and ready to land.Fri, Jul 26, 12:17 PM
This revision was automatically updated to reflect the committed changes.