[llvm-dev] OptBisect implementation for new pass manager

[Philip Pfaffe via llvm-dev]

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>