llvm dev - Sep 2018 - OptBisect implementation for new pass manager

Hi Andrew,

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.
>
At this point it makes no sense to worry about the code generation
pipeline. As long as there is no new-PM design for that, this point is just
moot. Designing opt-bisect against code generation without actually
understanding what we're designing against is guaranteed to produce a bad
architecture. So lets figure out the optimizer bisect first, and
incrementally upgrade that once we've ironed out codegen.


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.
>
> 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.
>
Mixing OptNone and bisect is a software engineering bug: it's mixing
different layers of abstraction. Bisect is something that's at pass manager
scope: run passes until whatever. OptNone in turn doesn't belong in the
pass manager layer. It only concerns function passes, and crumbles quickly
considering other IRUnits or even codegen. I don't have a clear vision what
OptNone handling should look like, but at this point I consider it entirely
orthogonal to bisect handling.
>From a software architecture perspective I don't see a reason why passes
should even _know_ about something like bisect happening. That is simply
not their domain. If a pass shouldn't be skipped for whatever reason,
that's not something the pass should worry about, that's the bisect
driver's problem! My proposal here would be make it an opt-out design, but
let the driver control that. E.g., for skipping, let the user provide a
list of passes they don't want skipped.


> 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 don't have a strong opinion here, but just as a data point: my mental
model here is to expect bisect to expect a deterministic outcome _per
module_. That model isn't threatened by parallel execution.


Cheers,
Philip

> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180927/20daa4aa/attachment.html>

Philip Pfaffe <philip.pfaffe at gmail.com> writes:
> If a pass shouldn't be skipped for whatever reason, that's not
> something the pass should worry about, that's the bisect driver's
> problem! My proposal here would be make it an opt-out design, but let
> the driver control that. E.g., for skipping, let the user provide a
> list of passes they don't want skipped.
I came to a similar conclusion while stuck in traffic yesterday.

Whether the model is opt-in or opt-out should not matter to pass
developers at all.  Passes should be completely unaware of bisect
because passes alone don't have enough information whether they should
opt in or opt out.

Only the thing that sets up the pass pipeline knows what the
requirements are.  I know we're not tackling codegen yet, but bear with
me.  Is scheduling required to run to produce a correct executable?  It
depends.  Different targets have different needs.  The scheduling pass
itself cannot know.  Whichever entity constructs the pass pipeline needs
to specify whether an added pass is required at that point.  Maybe that
same pass isn't required to run at some other point.

Whether bisect is opt-in or opt-out by default only affects the thing
constructing pass pipelines.  It has to decide what to tell the manager
of passes concerning its needs.

                            -David

> At this point it makes no sense to worry about the code generation
pipeline. As long as there is no new-PM design for that,
> this point is just moot. Designing opt-bisect against code generation
without actually understanding what we're designing
> against is guaranteed to produce a bad architecture. So lets figure out the
optimizer bisect first, and incrementally upgrade
> that once we've ironed out codegen.
I agree that we shouldn’t be speculatively designing for something that doesn’t
exist, but the ability to have the compilation result in executable code is a
firm requirement for me. We’re using the legacy code generation mechanism now,
so let’s design something that hooks up with that (as Sergeev suggested in his
original message). Where we go from there can certainly be deferred.
> Mixing OptNone and bisect is a software engineering bug: it's mixing
different layers of abstraction. Bisect is something that's
> at pass manager scope: run passes until whatever. OptNone in turn
doesn't belong in the pass manager layer. It only concerns
> function passes, and crumbles quickly considering other IRUnits or even
codegen. I don't have a clear vision what OptNone
> handling should look like, but at this point I consider it entirely
orthogonal to bisect handling.
In one sense you are absolutely right, OptNone and opt-bisect are completely
different things, but from the perspective of the pass they mean exactly the
same thing: should I optimize this IR unit. It’s also true that the pass
shouldn’t be making that decision, and it really isn’t in the legacy
implementation. It’s calling a function to ask whether or not it should perform
the optimization. That’s also less than ideal. In a perfect world, the pass
wouldn’t be called at all if it should be run. I think we’re actually in
agreement here with regard to OptBisect.

OptNone is out of the scope of the current proposal, but I agree that in
principle the pass manager shouldn’t be handling it. On the other hand, it’s not
entirely clear to me that the pass itself should be handling it. There is
nothing pass-specific in the interpretation of the OptNone attribute. The
OptNone attribute says “don’t optimize this function.” So should we really be
calling the run() method of an optimization pass on a function that we aren’t
supposed to be optimizing. It feels to me like there’s a missing player here. 
As I said, that’s really outside the scope of the current discussion except to
say that the relevant question is what component should make the decision about
whether or not a pass should be run.

So getting back to OptBisect, the problem is the same. What component should
decide whether or not a pass should be run? The pass manager doesn’t know what
the pass does, so it can’t decide whether or not it can be skipped. The pass
itself should have no idea that the OptBisect process even exists. So the pass
manager needs some way of discovering whether or not a pass can be skipped.

I don’t have strong feelings about how this happens. Off the cuff, it could be
added to the pass registration information or it could be a function provided by
the pass, preferably through one of the mixins so that pass developers don’t
need to think about it.

-Andy

From: Philip Pfaffe [mailto:philip.pfaffe at gmail.com]
Sent: Thursday, September 27, 2018 2:46 AM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: Fedor Sergeev <fedor.sergeev at azul.com>; llvm-dev <llvm-dev at
lists.llvm.org>; zhizhouy at google.com; dag at cray.com; David Blaikie
<dblaikie at gmail.com>; Chandler Carruth <chandlerc at gmail.com>
Subject: Re: [llvm-dev] OptBisect implementation for new pass manager

Hi Andrew,

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.
At this point it makes no sense to worry about the code generation pipeline. As
long as there is no new-PM design for that, this point is just moot. Designing
opt-bisect against code generation without actually understanding what we're
designing against is guaranteed to produce a bad architecture. So lets figure
out the optimizer bisect first, and incrementally upgrade that once we've
ironed out codegen.


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.

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.

Mixing OptNone and bisect is a software engineering bug: it's mixing
different layers of abstraction. Bisect is something that's at pass manager
scope: run passes until whatever. OptNone in turn doesn't belong in the pass
manager layer. It only concerns function passes, and crumbles quickly
considering other IRUnits or even codegen. I don't have a clear vision what
OptNone handling should look like, but at this point I consider it entirely
orthogonal to bisect handling.

From a software architecture perspective I don't see a reason why passes
should even _know_ about something like bisect happening. That is simply not
their domain. If a pass shouldn't be skipped for whatever reason, that's
not something the pass should worry about, that's the bisect driver's
problem! My proposal here would be make it an opt-out design, but let the driver
control that. E.g., for skipping, let the user provide a list of passes they
don't want skipped.


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 don't have a strong opinion here, but just as a data point: my mental
model here is to expect bisect to expect a deterministic outcome _per module_.
That model isn't threatened by parallel execution.


Cheers,
Philip

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<mailto:fedor.sergeev at
azul.com>]
Sent: Wednesday, September 26, 2018 9:54 AM
To: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>; Zhizhou Yang <zhizhouy at
google.com<mailto:zhizhouy at google.com>>; David Greene <dag at
cray.com<mailto:dag at cray.com>>; David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>>; Kaylor, Andrew
<andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>;
Chandler Carruth <chandlerc at gmail.com<mailto: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.

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180927/8175ec08/attachment.html>

On 09/28/2018 12:25 AM, Kaylor, Andrew wrote:
> As I said, that’s really outside the scope of the current discussion 
> except to say that the relevant question is what component should make 
> the decision about whether or not a pass should be run.
A planned way of implementation for new-pm's OptBisect is for 
instrumenting object to control the execution.
Whenever instrumentation bases its decisions on information provided by 
passes/pass managers,
it still has a final say.

So, whenever we choose opt-in or opt-out, it should happen either in 
OptBisect entirely,
or coordinated between passes/pass managers and OptBisect
object.
> So getting back to OptBisect, the problem is the same. What component 
> should decide whether or not a pass should be run? The pass manager 
> doesn’t know what the pass does, so it can’t decide whether or not it 
> can be skipped. The pass itself should have no idea that the OptBisect 
> process even exists. So the pass manager needs some way of discovering 
> whether or not a pass can be skipped.
Pass Manager's way of discovering that is to ask the BeforePass 
instrumentation.
We definitely do not want to add more decision-making points into pass 
manager.
The question is how OptBisect object gets the information for its decision.
> I don’t have strong feelings about how this happens. Off the cuff, it 
> could be added to the pass registration information or it could be a 
> function provided by the pass, preferably through one of the mixins so 
> that pass developers don’t need to think about it.
>
I'm leaning towards the registration-time activities, which perhaps 
means doing extra interaction between PassBuilder and OptBisect.
As we seem to favor the opt-out (and for current - non-CodeGen - 
implementation the out-out list appears to be empty? ) exact
mechanism of that out-out does not really bother me.

regards,
   Fedor.
> -Andy
>
> *From:*Philip Pfaffe [mailto:philip.pfaffe at gmail.com]
> *Sent:* Thursday, September 27, 2018 2:46 AM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>
> *Cc:* Fedor Sergeev <fedor.sergeev at azul.com>; llvm-dev 
> <llvm-dev at lists.llvm.org>; zhizhouy at google.com; dag at
cray.com; David
> Blaikie <dblaikie at gmail.com>; Chandler Carruth <chandlerc at
gmail.com>
> *Subject:* Re: [llvm-dev] OptBisect implementation for new pass manager
>
> Hi Andrew,
>
>     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.
>
> At this point it makes no sense to worry about the code generation 
> pipeline. As long as there is no new-PM design for that, this point is 
> just moot. Designing opt-bisect against code generation without 
> actually understanding what we're designing against is guaranteed to 
> produce a bad architecture. So lets figure out the optimizer bisect 
> first, and incrementally upgrade that once we've ironed out codegen.
>
>     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.
>
>     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.
>
> Mixing OptNone and bisect is a software engineering bug: it's mixing 
> different layers of abstraction. Bisect is something that's at pass 
> manager scope: run passes until whatever. OptNone in turn doesn't 
> belong in the pass manager layer. It only concerns function passes, 
> and crumbles quickly considering other IRUnits or even codegen. I 
> don't have a clear vision what OptNone handling should look like, but 
> at this point I consider it entirely orthogonal to bisect handling.
>
> From a software architecture perspective I don't see a reason why 
> passes should even _know_ about something like bisect happening. That 
> is simply not their domain. If a pass shouldn't be skipped for 
> whatever reason, that's not something the pass should worry about, 
> that's the bisect driver's problem! My proposal here would be make
it
> an opt-out design, but let the driver control that. E.g., for 
> skipping, let the user provide a list of passes they don't want
skipped.
>
>     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 don't have a strong opinion here, but just as a data point: my 
> mental model here is to expect bisect to expect a deterministic 
> outcome _per module_. That model isn't threatened by parallel
execution.
>
> Cheers,
>
> Philip
>
>     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
>     <mailto:fedor.sergeev at azul.com>]
>     Sent: Wednesday, September 26, 2018 9:54 AM
>     To: llvm-dev <llvm-dev at lists.llvm.org
>     <mailto:llvm-dev at lists.llvm.org>>; Zhizhou Yang
>     <zhizhouy at google.com <mailto:zhizhouy at google.com>>;
David Greene
>     <dag at cray.com <mailto:dag at cray.com>>; David Blaikie
>     <dblaikie at gmail.com <mailto:dblaikie at gmail.com>>;
Kaylor, Andrew
>     <andrew.kaylor at intel.com <mailto:andrew.kaylor at
intel.com>>;
>     Chandler Carruth <chandlerc at gmail.com <mailto: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.
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180928/3caa4622/attachment.html>

> Mixing OptNone and bisect is a software engineering bug: it's mixing
different layers of abstraction. Bisect is something that's
> at pass manager scope: run passes until whatever. OptNone in turn
doesn't belong in the pass manager layer. It only concerns
> function passes, and crumbles quickly considering other IRUnits or even
codegen. I don't have a clear vision what OptNone
> handling should look like, but at this point I consider it entirely
orthogonal to bisect handling.
In one sense you are absolutely right, OptNone and opt-bisect are completely
different things, but from the perspective of the pass they mean exactly the
same thing: should I optimize this IR unit. It’s also true that the pass
shouldn’t be making that decision, and it really isn’t in the legacy
implementation. It’s calling a function to ask whether or not it should perform
the optimization. That’s also less than ideal. In a perfect world, the pass
wouldn’t be called at all if it should be run. I think we’re actually in
agreement here with regard to OptBisect.

OptNone is out of the scope of the current proposal, but I agree that in
principle the pass manager shouldn’t be handling it. On the other hand, it’s not
entirely clear to me that the pass itself should be handling it. There is
nothing pass-specific in the interpretation of the OptNone attribute. The
OptNone attribute says “don’t optimize this function.” So should we really be
calling the run() method of an optimization pass on a function that we aren’t
supposed to be optimizing. It feels to me like there’s a missing player here. 
As I said, that’s really outside the scope of the current discussion except to
say that the relevant question is what component should make the decision about
whether or not a pass should be run.

Some historical perspective and clarification:

OptNone does not mean "don't optimize this function."  It means
"treat this function as much like –O0 would as you can."  (We thrashed
that one out when LTO started tagging functions with the optnone attribute.) 
Those are not completely identical statements; -O0 does run some passes.
Complications arise because there's only one pass pipeline in any given
compilation, and the pass manager doesn't know what the –O0 pipeline looks
like, but the –O0 pipeline is not empty.

Passes that don't normally run at –O0 were taught to query the helper. This
was not the originally proposed design, but at the time we introduced OptNone
there was serious push-back about adding a new feature to the old (at that time,
only) pass manager because the new pass manager was just over the horizon.  Five
years later it might be time to rethink that.

OptBisect built on OptNone because it was there.  Again there are passes that
have to run to produce usable output, even if you might think of them as
"optimization" passes, they would be part of the –O0 pipeline anyway
and they pretty much have to run no matter what.  I'm not close enough to
the problem to have a strong opinion whether OptBisect and OptNone should share
an underlying mechanism, but from the sidelines it seems like one readily
understandable model for OptBisect is "go this far down the regular
pipeline then turn on OptNone."  Maybe a different model would work better;
I'm not sure.
--paulr

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