[llvm-dev] OptBisect implementation for new pass manager

[Fedor Sergeev via llvm-dev]

Philip,

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.

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 <mailto: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 <mailto: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/296c49f0/attachment.html>