This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Serialize statistics to plist when serialize-stats=true is set
ClosedPublic

Authored by george.karpenkov on Feb 9 2018, 10:22 AM.

Diff Detail

Repository
rC Clang

Event Timeline

lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
191

Raw pointers are annoying, and it made no sense to me that the timer is statistic, yet is always initialized in constructor.

207

Having a group gives nicer statistics output, which explicitly states that this is an analyzer timer (as opposed to timer.misc.time)

216

I hate doing stuff in destructors, so I would much rather set PrintOnExit back to true, and remove the destructor altogether, but I was worried of making this CL too large.

576

Moving reset down is required to make sure the timer and extra statistics are available. Again, I would have liked to explicitly call flush or similar instead of relying on destructor, but it seemed out of place in this CL.

lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
493

I'm split between just adding it in an extra "statistics" field and having it as a comment. I would prefer the former, but I was afraid some random parser somewhere might choke.

Why not turn this on by default when we turn on reporting statistics?
Having a test for the plist output would be nice.

NoQ added inline comments.Feb 9 2018, 10:43 AM
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
493

I suspect that any "normal" parser (libplist of some sort) would accept both and any "dumb" parser (that parses the plist line-by-line with regexps and expect exact these lines) would choke on any of those with roughly the same probability. So i'm in favor of adding a field - at least those are being added more often, and dumb parser maintainers might be used to it by now.

NoQ added a comment.Feb 9 2018, 10:45 AM

So are these present only on translation units that actually caused bug reports to appear?

Having a test for the plist output would be nice.

I suspect such test would be super fragile. Every time we change any modeling, many of the stats may change.

In D43131#1003607, @NoQ wrote:

So are these present only on translation units that actually caused bug reports to appear?

Having a test for the plist output would be nice.

I suspect such test would be super fragile. Every time we change any modeling, many of the stats may change.

Using regex we could omit the actual numbers from the output checking.

NoQ added a comment.Feb 9 2018, 10:52 AM
In D43131#1003607, @NoQ wrote:

So are these present only on translation units that actually caused bug reports to appear?

Having a test for the plist output would be nice.

I suspect such test would be super fragile. Every time we change any modeling, many of the stats may change.

Using regex we could omit the actual numbers from the output checking.

Hmm, yay, great point! Then yeah, i'm all for tests =)

Why not turn this on by default when we turn on reporting statistics?

One issue is that LLVM timers can only be printed once (yeah, I know...) and serializing those numbers would "eat" the output, and then timers would not be displayed with -analyzer-stats.
But I guess I might as well fix the underlying problem.

Having a test for the plist output would be nice.

The problem is tests can be run on release configuration, which can not generate statistics at all. How could we check for that in a sensible way?

NoQ added a comment.Feb 9 2018, 11:06 AM

Having a test for the plist output would be nice.

The problem is tests can be run on release configuration, which can not generate statistics at all. How could we check for that in a sensible way?

Would // REQUIRES: asserts be relevant? I don't think there's any sort of // REQUIRES: debug, what exactly is needed here?
(https://llvm.org/docs/TestingGuide.html#constraining-test-execution)

Would // REQUIRES: asserts be relevant?

Ah right, that should work.

So if https://reviews.llvm.org/D43136 goes through, we could change this to print on -analyzer-stats or even always dumping statistics when an assertion-enabled build of clang is used.

NoQ added inline comments.Feb 9 2018, 5:17 PM
lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
494–497

Would this actually be a valid plist file? Maybe we should surround statistics with <string>...</string>?

lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
494–497

@NoQ EmitString inserts those

NoQ accepted this revision.Feb 9 2018, 5:29 PM

Yep, so i guess printing statistics as plist key-value pairs would be tricky. LGTM!~

lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
494–497

Oh, yay, nice. It seems that i didn't even look at the test.

This revision is now accepted and ready to land.Feb 9 2018, 5:29 PM
This revision was automatically updated to reflect the committed changes.