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.
+