[llvm] [DFAJumpThreading] Enable DFAJumpThread by default. (PR #157646)

[Nikita Popov via llvm-commits]

https://github.com/nikic approved this pull request.

>From https://llvm.org/docs/DeveloperPolicy.html#adding-or-enabling-a-new-llvm-pass:

> Maintenance: The pass (and any analyses it depends on) must have at least one maintainer.

The pass has two maintainers: https://github.com/llvm/llvm-project/blob/main/llvm/Maintainers.md#dfajumpthreading

> Usefulness: There should be evidence that the pass improves performance (or whatever metric it optimizes for) on real-world workloads. Improvements seen only on synthetic benchmarks may be insufficient.

There are improvements in benchmarks as indicated in the PR description. I also know that it helps zlib-rs performance. Generally I think it's pretty clear that this will provide real-world performance benefits for state machine type code. Which will only affect a small subset of code, but...

> Compile-Time: The pass should not have a large impact on compile-time, where the evaluation of what “large” means is up to reviewer discretion, and may differ based on the value the pass provides. In any case, it is expected that a concerted effort has been made to mitigate the compile-time impact, both for the average case, and for pathological cases.

...the latest [compile-time numbers](https://llvm-compile-time-tracker.com/compare.php?from=ed113e7904943565b4cd05588f6b639e40187510&to=2b901ca2e1b77d2b7a31cbcb57a921aa662341f9&stat=instructions:u) indicate that the pass is essentially free.

On [llvm-opt-benchmark](https://github.com/dtcxzyw/llvm-opt-benchmark/pull/3011) we do see some regressions (up to 20%) on specific files, but these are all cases where the transform triggers. Regressions mostly seem to be due to second order effects, where further compilation slows down after the transform. It's likely that this can be further mitigated, but I think the current state is good enough.

> Correctness: The pass should have no known correctness issues (except global correctness issues that affect all of LLVM). If an old pass is being enabled (rather than implementing a new one incrementally), additional due diligence is required. The pass should be fully reviewed to ensure that it still complies with current quality standards. Fuzzing with disabled profitability checks may help gain additional confidence in the implementation.

There are no open DFAJumpThreading issues that affect correctness, only one missed optimization issue (https://github.com/llvm/llvm-project/issues/70767).

I've not reviewed this code myself, but I believe @XChy has been looking at it a lot. There is probably more we could do to gain confidence in the correctness of the pass, but I think at this point I'm fine with flipping the switch.

LGTM

https://github.com/llvm/llvm-project/pull/157646