[llvm-dev] OptBisect implementation for new pass manager

[James Courtier-Dutton via llvm-dev]

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