[RFC] Pass traits support

IR & Optimizations
1

Background

New pass manager introduced pass instrumentation framework, one feature of this is it can decide whether to run current pass, two related examples are OptNoneInstrumentation and OptPassGateInstrumentation.
To avoid skipping unexpected passes, e.g. pass managers, pass must provide a isReqruied method:

struct SomenPass : PassInfoMixin {
  // ...
  static bool isRequired() { return true; }
};

Then PassInstrumentation::runBeforePass will ignore it and always run this pass.
This approach works fine with current IR pipeline, but for CodeGen pipeline this approach lacks expressiveness, because machine function passes can do lowering or optimization. Apparently, if a lowering pass provides isRequired, OptPassGateInstrumentation will no longer work for this pass. Thus we need a way to distinguish between optimization pass and lowering pass.

Proposed feature

The proposed feature is providing a PassInfo:

class PassInfo {
public:
  constexpr bool <pass trait>() { return <trait var>; }

  template<typename PassT>
  static constexpr PassInfo create() {
    // detect pass traits via type_traits
  }
private:
  bool <trait var> : 1;
};

And provide some other empty mixins, e.g. TransformPassMixin, so PassInfoMixin can calculate traits from std::is_base_of_v.

template<typename passT>
struct passInfoMixin {
// ...
  constexpr PassInfo getPassInfo() { /* check traits here and call overridePassInfo */ }
  constexpr void overridePassInfo(PassInfo &) {
    // Pass can override this if traits are determined by pass parameter.
  }
};
// will be a transform pass
struct TransformPass :PassInfoMixin<TransformPass>, TransformPassMixin {
  // ...
};

Traits in PassInfo should be atomic and composable. Some traits, based on LLVM’s Analysis and Transform Passes — LLVM 22.0.0git documentation, for example:

  • isAnalysisPass
  • is<IRUnit>Pass (may not well defined, due to dependency issue)
  • isPassAdaptor
  • isPassManager
  • isLoweringPass
  • isTransformPass
  • isUtilityPass

Passes with traits manager or adaptor will not participate in pass instrumentation, utility pass and lowering pass are not skippable by OptNoneInstrumentation like instrumentations, .

Other issues

  • These traits still can’t cover all cases, e.g. AlwaysInlinerPass but I think this part should be moved into instrumentation itself.
  • Should we provide high level traits like isIdempotent?
  • Should we support custom traits?

CC @aeubanks

2

From your description, I didn’t really understand what the problem with the current isRequired() is and how this related to optimization/lowering passes.

You say that OptPassGateInstrumentation not working if the pass returns true from isRequired(), but this is the part I don’t get. If the pass is required for correct lowering, we must not skip it during -opt-bisect, so the behavior is correct?