This is an archive of the discontinued LLVM Phabricator instance.

[GuardUtils] Allow intermmediate blocks between widenable branch and deopt block
ClosedPublic

Authored by skatkov on May 22 2023, 5:41 AM.

Diff Detail

Event Timeline

skatkov created this revision.May 22 2023, 5:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 22 2023, 5:41 AM
skatkov requested review of this revision.May 22 2023, 5:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 22 2023, 5:41 AM
nikic added a subscriber: nikic.May 22 2023, 6:02 AM
nikic added inline comments.
llvm/lib/Analysis/GuardUtils.cpp
54

Could cause an infinite loop if DeoptBB is part of a trivial cycle?

Why do we even care that an edge from a widenable condition branch terminates with a deopt? Widenable condition alone should be enough for widening.

We might want to know that a widened condition will result in a deopt for profitability purposes. We know that a deopt path is very unlikely and the runtime will be able to heal from the widening if we go that path. But we can check for these concerns separately and explicitly. We can use BFI to determine if a path is rare. We can introduce a new metadata to mark branches that can be healed after widening.

BTW, we use make implicit metadata for a similar purpose - to indicate that a branch can be "speculated" and the runtime can heal from this speculation.

skatkov updated this revision to Diff 524997.May 23 2023, 9:49 PM
skatkov marked an inline comment as done.May 23 2023, 9:52 PM

Why do we even care that an edge from a widenable condition branch terminates with a deopt? Widenable condition alone should be enough for widening.

We might want to know that a widened condition will result in a deopt for profitability purposes. We know that a deopt path is very unlikely and the runtime will be able to heal from the widening if we go that path. But we can check for these concerns separately and explicitly. We can use BFI to determine if a path is rare. We can introduce a new metadata to mark branches that can be healed after widening.

BTW, we use make implicit metadata for a similar purpose - to indicate that a branch can be "speculated" and the runtime can heal from this speculation.

Generally, I agree. But I propose to move step by step. This patch slightly increase the scope of optimization and does not touch what you mentioned as potential profitability.
I think that significant increase of an optimization scope might be done but it is a separate project. We can return to it back if needed.

llvm/lib/Analysis/GuardUtils.cpp
54

Thanks, fixed.

anna accepted this revision.May 24 2023, 10:46 AM

LGTM. I agree we can do the refactoring to profitability as follow-up.

llvm/lib/Analysis/GuardUtils.cpp
41

JFI: As part of the follow-up where the check is for profitability, rather than this being needed for functional correctness, we can collapse this entire block into IsBlockFollowedByDeoptOrUnreachable (since we need not check for mayHaveSideEffects).

This revision is now accepted and ready to land.May 24 2023, 10:46 AM
anna added inline comments.May 24 2023, 10:49 AM
llvm/lib/Analysis/GuardUtils.cpp
41

that API has also the benefit it has a cut-off for successor walking: MaxDeoptOrUnreachableSuccessorCheckDepth.

This revision was landed with ongoing or failed builds.May 25 2023, 2:42 AM
This revision was automatically updated to reflect the committed changes.
skatkov marked an inline comment as done.