[PATCH] D18576: Initial implementation of optimization bisect

[Matthias Braun via llvm-commits]

> On Apr 14, 2016, at 12:09 PM, Andy Kaylor via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> andrew.w.kaylor added a comment.
> 
> The new pass manager design also presents a problem in terms of creating a single, simple check function that goes through the LLVMContext.  Right now, I'm testing with the global singleton like this:
> 
>  if (!getOptBisect().shouldRunPass(name(), &F))
>    return PreservedAnalyses::all();
> 
> Trying to move that into the context yields something like this:
> 
>  if (!F.getContext().getOptBisect().shouldRunPass(name(), &F))
>    return PreservedAnalyses::all();
> 
> That's not terrible, but for loop passes it becomes this:
> 
>  if (auto *F = L->getHeader()->getParent()) {
>    LLVMContext &Context = F->getContext();
>    if (!Context.getOptBisect().shouldRunPass(this, L))
>      return PreservedAnalyses::all();
>  }
I'm not saying it is pretty, I am also not sure there is a really pretty solution. However what I find important here is that we already have the mechanisms dealing with Optnone which is solving a very similar problems (skipping passes on some condition while not doing that for 'essential' passes).
In this case LoopPass::skipOptnoneFunction() looks similar. As with my last pseudo code I would assume we can also rename LoopPass::skipOptnoneFunction() to a more generic name like LoopPass::skipRun() and check for OptNone and the bisection counter in the same function.
I think that would allow us to hook up the bisection stuff with no additional code lines necessary in the individual passes (as renaming skipOptnoneFunction() to skipFunction() will keep the same size).

> 
> I could provide global helper functions that perform this check, but that has the feel of false encapsulation.

Sure, should be doable without repeating the ugly pattern and having it in a single helper function.

- Matthias