This is an archive of the discontinued LLVM Phabricator instance.

add control flags to LICM
AbandonedPublic

Authored by sebpop on Jun 3 2016, 1:10 PM.

Details

Summary

This patch adds -licm-max-hoist and -licm-max-sink to debug the LICM pass.

Diff Detail

Repository
rL LLVM

Event Timeline

sebpop updated this revision to Diff 59607.Jun 3 2016, 1:10 PM
sebpop retitled this revision from to add control flags to LICM.
sebpop updated this object.
sebpop added reviewers: dberlin, majnemer.
sebpop set the repository for this revision to rL LLVM.
sebpop added a subscriber: llvm-commits.
dberlin edited edge metadata.Jun 3 2016, 1:12 PM
dberlin added a subscriber: dberlin.

I swear there was a more generic debug counting proposal a few months ago.

I swear there was a more generic debug counting proposal a few months ago.

You probably think of http://reviews.llvm.org/D19172. Maybe it's enough to add some more function to OptBisect there. Andrew Kaylor should know more.

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.

sebpop added a comment.Jun 6 2016, 1:58 PM

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

I was trying to completely disable LICM for perf analysis, not bisecting a correctness problem with LICM.
I will modify the patch to use opt-bisect. Thanks for the review.

I was trying to completely disable LICM for perf analysis, not bisecting a correctness problem with LICM.

In that case, opt-bisect may not do what you need, because it will disable all optimizations after this as well. Several other passes have options to completely disable them apart from the opt-bisect option. It would still be nice to have case-by-case bisect support here, but if that's not what you wanted I can add that later.

sebpop abandoned this revision.Aug 26 2016, 8:03 PM