[PATCH] D99205: Add jump-threading optimization for deterministic finite automata

Sjoerd Meijer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 9 03:09:17 PDT 2021


SjoerdMeijer added a comment.

In D99205#2866301 <https://reviews.llvm.org/D99205#2866301>, @ChuanqiXu wrote:

> I am making an AggressiveJumpThreading pass in  downstream to solve the State Machine in Coremark.

We have 2 aggressive jump threading passes in upstream review: this work, and also D88307 <https://reviews.llvm.org/D88307>. If I understand this correctly, you're working on another downstream? If so, would it not be more efficient if we support this work? For me, this work has the most potential as it is under active development as opposed to D88307 <https://reviews.llvm.org/D88307>. Your remark about irreducible control flow is a valid one, which was made earlier too. Eli said this about that:

> This is kind of late to be running this pass. That might be useful in some cases: we might be making the code harder to analyze if there's irreducible control flow. On the other hand, we're skipping interesting optimizations if the CFG becomes significantly simpler. My instinct is that the advantages of running earlier outweigh the disadvantages.

which is something that still needs to be figured out I think. I.e., it's run earlier now, but do we need more performance numbers to see if this doesn't regress other stuff? But @ChuanqiXu, if you're working on something similar and have ideas, please consider sharing them here.

> And I omit the problem that more aggressive jump threading would cause irreducible control flow. I heard about that gcc has implemented a version which overcomes the problem. It may be beneficial to look into the details of the gcc implementation for all of us.
> This patch looks like a big pattern match to me. It requires a switch statement whose condition are predictable, in other words, DFA.
> First question is that is it profitable to make a pass for specific pattern? Since I feel that the DFA pattern wouldn't be normal in codes. Then if the pass turned off by default, I have no problems.

My colleague @jaykang10 found that this also triggers on Perlbench in SPEC.


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

https://reviews.llvm.org/D99205



More information about the llvm-commits mailing list