[PATCH] D152639: [LoopUnrollRuntime] Allow simple transition to deopt non-latch exit blocks

Yevgeny Rouban via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 12 21:28:00 PDT 2023


yrouban added a comment.

In D152639#4415300 <https://reviews.llvm.org/D152639#4415300>, @anna wrote:

> If we are traversing through unique successors until we reach deopt, we're guaranteed it is a cold path. Did we get any compile time difference if we choose this heuristic versus directly using `getPostdominatingDeoptimizeCall()`?
> When I originally had the heuristic, there wasn't any particular reason for checking immediate deopt block (except that those were the workloads we cared about).

I agree that relaxing the unroll condition we might end up with a longer compile time (CT), but this change has nothing to do with CT (e.g. the longer chain of transitive blocks does not contribute to a bigger IR after unrolling). If we will have a longer CT with this change it could be so with the original code. I believe that if we want to limit impact of LoopUnroll on CT we have to impose a cost model to estimate the effect of unrolling - that is what said in the TODO right after the return statement. So, I will if there will be found any CT increase.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152639/new/

https://reviews.llvm.org/D152639



More information about the llvm-commits mailing list