[llvm-dev] OptBisect implementation for new pass manager (original) (raw)

James Courtier-Dutton via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 28 15:06:55 PDT 2018

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>

More information about the llvm-dev mailing list