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.
Ted
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
