[llvm-dev] OptBisect implementation for new pass manager

Fedor Sergeev via llvm-dev
Thu, 27 Sep 2018 14:13:59 -0000

On 09/27/2018 02:18 AM, Kaylor, Andrew wrote:
> We absolutely need to be able to generate executable programs using
opt-bisect, so some mechanism for not skipping required passes is needed. It
might be nice to have a mode where no passes are skipped and the IR/MIR is
dumped when the bisect limit is reached, but I don't see that as a
requirement.
Do you expect this dumping functionality to be used directly by users,
or is it going to be fed into some tool?
(implementing something like that should not present any difficulties,
basically it is just a merge of two instrumentations -
print-after=<optbisect-number>)
> Regarding opt-in versus opt-out, I think we want to make this as easy and
transparent to pass developers as possible. It would be nice to have the
mechanism be opt-out so that passes that were added with no awareness of
opt-bisect would be automatically included. However, there is a small wrinkle to
this. I can't defend this as a reasonable design choice, but the
SelectionDAGISel pass has a sort of hybrid behavior. It can't actually be
skipped, but it OptBisect says it should be skipped it drops the optimization
level to OptNone. That's a machine function pass, so it doesn't matter
so much right now. It's just something to think about.
It does sound like a hack :)
Perhaps it needs a direct integration with OptBisect?

regards,
   Fedor.

> One of the reasons that we combined the optnone handling and the opt-bisect
handling is that we specifically wanted these two behaviors to be linked. The
exact rule we would like to use for opt bisect is that no pass which runs at O0
is skipped by opt-bisect. There's a test that verifies this. Conversely, if
a pass is able to respect the optnone attribute then it should also be skippable
by opt-bisect. Of course, I would be open to considering a use case where this
reasoning isn't desirable.
>
>
> 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.
>
> -Andy
>
> -----Original Message-----
> From: Fedor Sergeev [mailto:fedor.sergeev at azul.com]
> Sent: Wednesday, September 26, 2018 9:54 AM
> To: llvm-dev <llvm-dev at lists.llvm.org>; Zhizhou Yang <zhizhouy
at google.com>; David Greene <dag at cray.com>; David Blaikie
<dblaikie at gmail.com>; Kaylor, Andrew <andrew.kaylor at
intel.com>; Chandler Carruth <chandlerc at gmail.com>
> Subject: OptBisect implementation for new pass manager
>
> 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.
>