[llvm-dev] parallel OptBisect

[Fedor Sergeev via llvm-dev]

On 09/27/2018 02:18 AM, Kaylor, Andrew wrote:
> With regard to there being one OptBisect object per compilation pipeline, I have some concerns. Specifically, the behavior of opt-bisect depends on the sequence of passes run before the limit is reached being consistent and repeatable. My inclination would be to not allow parallel compilation when opt-bisect is enabled. I can imagine cases where you might specifically want to debug something that only happens in a parallel build, but it's more difficult to imagine something that only happens in a parallel build and doesn't depend on interactions between threads. In such a case, would we be able to guarantee that the sequence of passes and any interaction between pipelines was repeatable. Basically, here I feel like I'm exploring a hypothetical idea where other people have specific use cases. If so, please explain the use case to me.
Well, I did not really mean to emphasize parallel compilation topic here.
But as you asked - our JIT compiler which is LLVM library linked into 
java machine typically performs
multiple parallel compilations, each compiling a separate module from a 
separate context in a single thread.
It is not your typical fully-parallel compilation since every compile is 
independent on LLVM level.
However as it is a library in a single process, it does share all the 
globals, OptBisect object in particular.
Naturally, that makes -opt-bisect-limit usage for live in-VM compilation 
rather problematic.

Having OptBisect object handled separately for each individual 
compilation pipeline enables us
with ability to apply bisection to the live in-VM compilation.
(recently we did introduce OptPassGate interface that allows to install 
a different OptBisect for each context,
but it is much less clean than what we can get with new-pm).

regards,
   Fedor.