On Oct 26, 2012, at 9:08 , Ted Kremenek <[email protected]> wrote: > On Oct 25, 2012, at 3:59 PM, Jordan Rose <[email protected]> wrote: > >>> /// Recursively scan through a path and prune out calls and macros pieces >>> /// that aren't needed. Return true if afterwards the path contains >>> /// "interesting stuff" which means it should be pruned from the parent >>> path. >>> @@ -2016,10 +2078,16 @@ >>> } while(finalReportConfigToken != originalReportConfigToken); >>> >>> // Finally, prune the diagnostic path of uninteresting stuff. >>> - if (!PD.path.empty() && R->shouldPrunePath()) { >>> - bool hasSomethingInteresting = >>> RemoveUneededCalls(PD.getMutablePieces(), R); >>> - assert(hasSomethingInteresting); >>> - (void) hasSomethingInteresting; >>> + if (!PD.path.empty()) { >>> + // Remove messages that are basically the same. >>> + RemoveRedundantMsgs(PD.getMutablePieces()); >>> + >>> + if (R->shouldPrunePath()) { >>> + bool hasSomethingInteresting = >>> RemoveUneededCalls(PD.getMutablePieces(), >>> + R); >>> + assert(hasSomethingInteresting); >>> + (void) hasSomethingInteresting; >>> + } >> >> It's probably cheaper to do this in the other order. > > Hi Jordan, > > That is true, but I think RemoveUneededCalls should always come last, after > we have done all of other passes over the PathPieces. The idea is that the > more we remove from the path, there is a higher chance that > RemoveUneededCalls will be able to remove a call. That won't apply in this > scenario because of how RemoveRedundantMsgs works, but it's something that > would be easy to get wrong if we added more "passes" like this where the > implications are slightly different.
Okay, makes sense!
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
