[PATCH] D146276: [GuardWidening] Improve analysis of potential widening into hotter block

[Max Kazantsev via Phabricator via llvm-commits]

mkazantsev created this revision.
mkazantsev added reviewers: skatkov, anna, reames, nikic, lebedev.ri, fhahn.
Herald added subscribers: StephenFan, hiraditya.
Herald added a project: All.
mkazantsev requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

There is a piece of logic in GuardWidening which is very limited, and it happens
to ignore implicit control flow, therefore it "works fine" with guards expressed as
intrinsic calls. However, when the guards are represented as branches, its limitations
create a lot of trouble.

The intent here is to make sure that we do not widen code across complex CFG,
so that it can end up being in hotter code than it used to be. The old logic was limited
to unique immediate successor and that's it.

This patch changes the logic there to work the following way: when we need to check
if we can widen from `DominatedBlock` into `DominatingBlock`, we first try to find the
lowest (by CFG) transitive successor  of `DominatingBlock` which is guaranteed to not
be significantly colder than the `DominatingBlock`. It means that every time we move
to either:

- Unique successor of the current block, if it only has one successor;
- The only taken successor, if the current block ends with `br(const)`;
- Guarded block, if the current block is terminated by a guard.

If the lowest block we can find this way is the `DominatedBlock`, then it is safe to assume
that this widening won't move the code into a hotter location.

I did not touch the existing check with PDT. It looks fishy to me (post-dominance doesn't
really guarantee anything about hotness), but let's keep it as is and maybe fix later.

With this patch, Guard Widening can widen explicitly expressed branches across more than one
dominating guard if it's profitable.


https://reviews.llvm.org/D146276

Files:
  llvm/lib/Transforms/Scalar/GuardWidening.cpp
  llvm/test/Transforms/GuardWidening/two_forms_behavior_consistency.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D146276.506009.patch
Type: text/x-patch
Size: 9148 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230317/d3ac8539/attachment-0001.bin>