<div dir="ltr">Hi Fedor,<div><br></div><div>can you make an example where a pass actually needs to opt-out? Because IMO, bisect should quite literally to DebugCounter-style skip every step in every ::run method's loop. Passes should not even be concerned with this.</div><div><br></div><div>Cheers,</div><div>Philip</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 6:54 PM Fedor Sergeev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings!<br>
<br>
As the generic Pass Instrumentation framework for new pass manager is <br>
finally *in*,<br>
I'm glad to start the discussion on implementation of -opt-bisect <br>
through that framework.<br>
<br>
As it has already been discovered while porting other features (namely, <br>
-time-passes)<br>
blindly copying the currently existing legacy implementation is most <br>
likely not a perfect<br>
way forward. Now is a chance to take a fresh look at the overall <br>
approach and perhaps<br>
do better, without the restrictions that legacy pass manager framework <br>
imposed on<br>
the implementation.<br>
<br>
Kind of a summary of what we have now:<br>
   - There is a single OptBisect object, requested through LLVMContext<br>
     (managed as ManagedStatic).<br>
<br>
   - OptBisect is defined in lib/IR, but does use analyses,<br>
     which is a known layering issue<br>
<br>
   - Pass hierarchy provides skipModule etc helper functions<br>
<br>
   - Individual passes opt-in to OptBisect activities by manually <br>
calling skip* helper functions<br>
     whenever appropriate<br>
<br>
With current state of new-pm PassInstrumentation potential OptBisect <br>
implementation<br>
will have the following properties/issues:<br>
   - OptBisect object that exists per compilation pipeline, managed <br>
similar to PassBuilder/PassManagers<br>
     (which makes it more suitable for use in parallel compilations)<br>
<br>
   - no more layering issues imposed by implementation since <br>
instrumentations by design<br>
     can live anywhere - lib/Analysis, lib/Passes etc<br>
<br>
   - since Codegen is still legacy-only we will have to make a joint <br>
implementation that<br>
     provides a sequential passes numbering through both new-PM IR and <br>
legacy Codegen pipelines<br>
<br>
   - as of right now there is no mechanism for opt-in/opt-out, so it <br>
needs to be designed/implemented<br>
     Here I would like to ask:<br>
         - what would be preferable - opt-in or opt-out?<br>
<br>
         - with legacy implementation passes opt-in both for bisect and <br>
attribute-optnone support at once.<br>
           Do we need to follow that in new-pm implementation?<br>
<br>
Also, I would like to ask whether people see current user interface for <br>
opt-bisect limiting?<br>
Do we need better controls for more sophisticated bisection?<br>
Basically I'm looking for any ideas on improving opt-bisect user <br>
experience that might<br>
affect design approaches we take on the initial implementation.<br>
<br>
regards,<br>
   Fedor.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>