[llvm-dev] OptBisect implementation for new pass manager

[Fedor Sergeev via llvm-dev]

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.