[llvm-dev] OptBisect implementation for new pass manager

Fedor Sergeev via llvm-dev
Wed, 26 Sep 2018 16:53:52 -0000

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.