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

Philip Pfaffe via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 10:47:47 PDT 2018

Hi Fedor,

can you make an example where a pass actually needs to opt-out? Because IMO, bisect should quite literally to DebugCounter-style skip every step in every ::run method's loop. Passes should not even be concerned with this.

Cheers, Philip

On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote:

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.

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/7e5a4d41/attachment.html>

More information about the llvm-dev mailing list