Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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. |
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). |
llvm/lib/Analysis/GuardUtils.cpp | ||
---|---|---|
41 | that API has also the benefit it has a cut-off for successor walking: MaxDeoptOrUnreachableSuccessorCheckDepth. |
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).