From 7605b29e27723e3d702cf9dc7fc7e3b60d2405a5 Mon Sep 17 00:00:00 2001 From: Joel Jones Date: Fri, 20 Apr 2012 18:11:07 +0000 Subject: [PATCH] Add debugging hints for when bugpoint does not suffice, specifically for instcombine and TargetLowering git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155209 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/Bugpoint.html | 77 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html index bcd34b84499..2c0cb779e2c 100644 --- a/docs/Bugpoint.html +++ b/docs/Bugpoint.html @@ -21,6 +21,7 @@
  • Miscompilation debugger
  • Advice for using bugpoint
    • +
  • What to do when bugpoint isn't enough
    • @@ -219,6 +220,82 @@ non-obvious ways. Here are some hints and tips:

    kills bugpoint. +

    + +

    + What to do when bugpoint isn't enough +

    + + +
    + +

    Sometimes, bugpoint is not enough. In particular, InstCombine and +TargetLowering both have visitor structured code with lots of potential +transformations. If the process of using bugpoint has left you with +still too much code to figure out and the problem seems +to be in instcombine, the following steps may help. These same techniques +are useful with TargetLowering as well.

    + +

    Turn on -debug-only=instcombine and see which transformations +within instcombine are firing by selecting out lines with "IC" +in them.

    + +

    At this point, you have a decision to make. Is the number +of transformations small enough to step through them using a debugger? +If so, then try that.

    + +

    If there are too many transformations, then a source modification +approach may be helpful. +In this approach, you can modify the source code of instcombine +to disable just those transformations that are being performed on your +test input and perform a binary search over the set of transformations. +One set of places to modify are the "visit*" methods of +InstCombiner (e.g. visitICmpInst) by adding a +"return false" as the first line of the method.

    + +

    If that still doesn't remove enough, then change the caller of +InstCombiner::DoOneIteration, InstCombiner::runOnFunction +to limit the number of iterations.

    + +

    You may also find it useful to use "-stats" now to see what parts +of instcombine are firing. This can guide where to put additional reporting +code.

    + +

    At this point, if the amount of transformations is still too large, then +inserting code to limit whether or not to execute the body of the code +in the visit function can be helpful. Add a static counter which is +incremented on every invocation of the function. Then add code which +simply returns false on desired ranges. For example:

    + +
    +

    static int calledCount = 0;

    +

    calledCount++;

    +

    DEBUG(if (calledCount < 212) return false);

    +

    DEBUG(if (calledCount > 217) return false);

    +

    DEBUG(if (calledCount == 213) return false);

    +

    DEBUG(if (calledCount == 214) return false);

    +

    DEBUG(if (calledCount == 215) return false);

    +

    DEBUG(if (calledCount == 216) return false);

    +

    DEBUG(dbgs() << "visitXOR calledCount: " << calledCount + << "\n");

    +

    DEBUG(dbgs() << "I: "; I->dump());

    +
    + +

    could be added to visitXOR to limit visitXor to being +applied only to calls 212 and 217. This is from an actual test case and raises +an important point---a simple binary search may not be sufficient, as +transformations that interact may require isolating more than one call. +In TargetLowering, use return SDNode(); instead of +return false;.

    + +

    Now that that the number of transformations is down to a manageable +number, try examining the output to see if you can figure out which +transformations are being done. If that can be figured out, then +do the usual debugging. If which code corresponds to the transformation +being performed isn't obvious, set a breakpoint after the call count +based disabling and step through the code. Alternatively, you can use +"printf" style debugging to report waypoints.

    +