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

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 26 11:45:17 PDT 2018

opt-bisect is often used to debug why a program compiled at -O0 produces different output to a program compiled at -O1 or -O2. We want to eliminate the bad pass/optimization but still produce a working executable.

~Craig

On Wed, Sep 26, 2018 at 11:41 AM Philip Pfaffe via llvm-dev < llvm-dev at lists.llvm.org> wrote:

It kinda depends on user expectations. What do you really expect as a result of your compilation when you set -opt-bisect-limit=X? Do you just get a resulting IR and scan for the bad pattern? Then you dont care about pass sequences and do brute-force bisect.

This is what I'd expect.

Do you expect to get a runnable code at the end and check for buggy run-time behavior? Then you need to keep the passes that are required to produce runnable code. In our Java JIT compiler we have quite a number of passes where we lower the semantics to C level and those lowerings are absolutely required for the code to be runnable. regards, Fedor. On 09/26/2018 08:47 PM, Philip Pfaffe wrote: 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

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/5a6eb359/attachment.html>

More information about the llvm-dev mailing list