[llvm-dev] OptBisect implementation for new pass manager

[Craig Topper via llvm-dev]

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>