[llvm-dev] OptBisect implementation for new pass manager

[Philip Pfaffe via llvm-dev]

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/d5861eb8/attachment.html>