[llvm-dev] OptBisect implementation for new pass manager

[Kaylor, Andrew via llvm-dev]

> I don't think I can help this discussion, but I would like to understand the context of it.
> Do we have any requirements?
> What are the use cases that "opt-bisect" is intended to help with?

Basically, it’s meant to help isolate the pass that introduced problems that occur in optimized code. I mainly use it to debug failures that occur when a program is run, but it’s a pretty general facility and can be used in many ways.

It’s documented here: https://llvm.org/docs/OptBisect.html


> Q1) Take LLVM IR instruction X.
> Which pass removed it (optimized it out) ?

Opt-bisect, combined with the bisect script in utils, can help with this. You’d need to provide some script that knows how to detect the IR change you’re interested in. I’ve used opt-bisect for this. I think you can do this with bugpoint too, but you wouldn’t enjoy it.


> Q2) Take LLVM IR instruction X.
> Run pass Y once. Leaves instruction X in there.
> Run pass Y a second time should not then remove instruction X.
> My thinking that if pass Y was doing its job correctly, it should have removed instruction X on the first pass Y. i.e. pass Y should not be lazy.
> One problem with the "lazy" approach, is "How many times should pass Y be run?"

I don’t think opt-bisect helps with this.


> Q3) Do any LLVM IR passes do delayed instruction elimination?
> I.e.
> Pass 1 marks some instructions for removal.
> Pass 2 marks some more instructions for removal.
> Pass 3 actually removes the instructions. (the expensive bit where caches, indexes etc. need rebuilding)
> I only mention this Q3, because I think it could affect the way opt-bisect should work. (see Q1 above) Should the answer be Pass 1 or Pass 3 ?

I don’t believe this kind of dependency between passes is supposed to happen.  There are some gray areas, I guess, like one pass can add metadata that another pass interprets in such a way that it decides to delete instructions. In any event, the IR should be complete and legal after each pass, so if someone decides to implement passes this way I think they’re on their own determined what to make of the opt-bisect results.

-Andy



From: James Courtier-Dutton [mailto:james.dutton at gmail.com]
Sent: Friday, September 28, 2018 3:07 PM
To: fedor.sergeev at azul.com
Cc: llvm-dev <llvm-dev at lists.llvm.org>; zhizhouy at google.com; dag at cray.com; David Blaikie <dblaikie at gmail.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; chandlerc at gmail.com
Subject: Re: [llvm-dev] OptBisect implementation for new pass manager

On Wed, 26 Sep 2018 at 17:54, 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.

I don't think I can help this discussion, but I would like to understand the context of it.
Do we have any requirements?
What are the use cases that "opt-bisect" is intended to help with?

Some use cases that I would like to understand are:
Q1) Take LLVM IR instruction X.
Which pass removed it (optimized it out) ?
Q2) Take LLVM IR instruction X.
Run pass Y once. Leaves instruction X in there.
Run pass Y a second time should not then remove instruction X.
My thinking that if pass Y was doing its job correctly, it should have removed instruction X on the first pass Y. i.e. pass Y should not be lazy.
One problem with the "lazy" approach, is "How many times should pass Y be run?"
Q3) Do any LLVM IR passes do delayed instruction elimination?
I.e.
Pass 1 marks some instructions for removal.
Pass 2 marks some more instructions for removal.
Pass 3 actually removes the instructions. (the expensive bit where caches, indexes etc. need rebuilding)
I only mention this Q3, because I think it could affect the way opt-bisect should work. (see Q1 above) Should the answer be Pass 1 or Pass 3 ?

Is opt-bisect something that can help with these use cases?

Kind Regards

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180928/7faa419c/attachment.html>