[llvm-dev] OptBisect implementation for new pass manager (original) (raw)

Fedor Sergeev via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 09:53:52 PDT 2018

Greetings!

As the generic Pass Instrumentation framework for new pass manager is finally in, I'm glad to start the discussion on implementation of -opt-bisect through that framework.

As it has already been discovered while porting other features (namely, -time-passes) blindly copying the currently existing legacy implementation is most likely not a perfect way forward. Now is a chance to take a fresh look at the overall approach and perhaps do better, without the restrictions that legacy pass manager framework imposed on the implementation.

Kind of a summary of what we have now:   - There is a single OptBisect object, requested through LLVMContext     (managed as ManagedStatic).

  - OptBisect is defined in lib/IR, but does use analyses,     which is a known layering issue

  - Pass hierarchy provides skipModule etc helper functions

  - Individual passes opt-in to OptBisect activities by manually calling skip* helper functions     whenever appropriate

With current state of new-pm PassInstrumentation potential OptBisect implementation will have the following properties/issues:   - OptBisect object that exists per compilation pipeline, managed similar to PassBuilder/PassManagers     (which makes it more suitable for use in parallel compilations)

  - no more layering issues imposed by implementation since instrumentations by design     can live anywhere - lib/Analysis, lib/Passes etc

  - since Codegen is still legacy-only we will have to make a joint implementation that     provides a sequential passes numbering through both new-PM IR and legacy Codegen pipelines

  - as of right now there is no mechanism for opt-in/opt-out, so it needs to be designed/implemented     Here I would like to ask:         - what would be preferable - opt-in or opt-out?

        - with legacy implementation passes opt-in both for bisect and attribute-optnone support at once.           Do we need to follow that in new-pm implementation?

Also, I would like to ask whether people see current user interface for opt-bisect limiting? Do we need better controls for more sophisticated bisection? Basically I'm looking for any ideas on improving opt-bisect user experience that might affect design approaches we take on the initial implementation.

regards,   Fedor.

More information about the llvm-dev mailing list