[PATCH] D142725: [DFAJumpThreading] Enable DFAJT with LTO

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 1 01:36:31 PST 2023


nikic added a reviewer: fhahn.
nikic added a subscriber: fhahn.
nikic added a comment.
Herald added a subscriber: StephenFan.

In D142725#4086788 <https://reviews.llvm.org/D142725#4086788>, @martong wrote:

> Okay, that makes sense to me. There is, however, something that still bothers me. There is the old `JumpThreadingPass` which is added both to the function simplification pipeline and to the LTO pipeline. So,  adding `DFAJumpThreading` to the LTO pipeline would make it consistent with the way how the old `JumpThreadingPass` is added to these pipelines, isn't it?

These passes aren't really comparable, even if they both have jump threading in their name. JumpThreading is a basic control-flow optimization pass. It's going to be able to do some useful work pretty much anytime additional inlining opportunities arise. DFAJumpThreading is a pass targeting a very specific pattern -- for LTO to be useful, part of the DFA switch structure must only become visible as a result of LTO. Not impossible, but probably also not particularly common?

That said, I do find the argument compelling in abstract. However, it's not really clear to me how we decide which passes get rerun during LTO and which don't. Maybe @fhahn has some insight there.

If we run the pass during LTO, I'm not sure the proposed position is the right one (the same applies to the position of the ConstraintElimination pass next to it). The FPM this is being added to is commented as "Run a few AA driver optimizations here and now to cleanup the code". It's an FPM that gets run before FuncAttrs and GlobalsAA. There is a MainFPM after it, where most of the passes are scheduled.

Generally, after looking at it just now, I find the way the fat LTO pipeline is structured extremely confusing. Normally we structure the pipeline into a simplification pipeline that gets run as part of a CGSCC pass manager with the inliner, and an optimization pipeline that runs afterwards. However, fat LTO appears to schedule the inliner without any other passes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142725



More information about the llvm-commits mailing list