[PATCH] D20984: add control flags to LICM

[Andy Kaylor via llvm-commits]

andrew.w.kaylor added a comment.

You definitely could (and I think should) do this with opt-bisect.

I haven't added support anywhere to make the interface pretty, but it would look something like this:

  static bool sink(Instruction &I, const LoopInfo *LI, const DominatorTree *DT,
                   const Loop *CurLoop, AliasSetTracker *CurAST,
                   const LICMSafetyInfo *SafetyInfo) {
    const Function *F = L->getHeader()->getParent();
    if (!F)
      return false;
    // Check the opt bisect limit.
    LLVMContext &Context = F->getContext();
    if (!Context.getOptBisect().shouldRunCase("sink instruction: " + I.getName()))
      return false;

Most of the ugliness there is just trying to get the Context from the Loop.  The various pass types have helper functions to hide those details, but I don't have anything yet that could be used in a place like this.

I'd like to have an overloaded helper function that would let you do something like this, but it isn't there yet:

  static bool sink(Instruction &I, const LoopInfo *LI, const DominatorTree *DT,
                   const Loop *CurLoop, AliasSetTracker *CurAST,
                   const LICMSafetyInfo *SafetyInfo) {
    if (!getOptBisect(L).shouldRunCase("sink instruction: " + I.getName()))
      return false;

Anyway, if you added that code you could use "-opt-bisect-limit=-1" to find the place where the sinks and hoists were occurring and then "-opt-bisect-limit=<n>" to cut it off.  You might have other optimizations sneaking in between groups of sinks and hoists, but assuming you have an observable problem that is being caused by a sink or hoist a simple bisect using this option would find it without your having to think about those details.


Repository:
  rL LLVM

http://reviews.llvm.org/D20984