This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Print time taken to analyze each function
ClosedPublic

Authored by RithikSharma on Jul 7 2021, 10:54 AM.

Details

Summary

This patch is a part of an attempt to obtain more timer data from the analyzer. In this patch, we try to use LLVM::TimeRecord to save time before starting the analysis and to print the time that a specific function takes while getting analyzed.

The timer data is printed along with the -analyzer-display-progress outputs.

ANALYZE (Syntax): test.c functionName : 0.4 ms 
ANALYZE (Path,  Inline_Regular): test.c functionName : 2.6 ms

Diff Detail

Event Timeline

RithikSharma created this revision.Jul 7 2021, 10:54 AM
RithikSharma requested review of this revision.Jul 7 2021, 10:54 AM
NoQ added a comment.Jul 7 2021, 12:16 PM

Yay! Did you figure out how to update the tests?

clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
119–121

I don't think this problem requires "global mutable state"(tm). What prevents you from doing it with just local variables? I.e., something like:

DisplayFunction();
TimeRecord T1 = ExprEngineTimer->getTotalTime();
RunPathSensitiveChecks();
TimeRecord T2 = ExprEngineTimer->getTotalTime();
T2 -= T1;
PrintTime(T2);
652

Delaying DisplayFunction() until the analysis is finished is unfortunate because if something goes wrong during analysis (eg., a debugger breakpoint hits), we wouldn't have a fancy print for which function was analyzed. Can we print the function first but have another print later for the timer?

Good to see some progress in this direction.

clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
226–243

I think this is somewhat shorter.

TBH I don't know if the if guarding this block is strictly necessary. An assertion might be enough IDK.

Let me digress a bit if we are at this code.
It was always so annoying that this display progress printed *only* the function name.
On the other hand the -analyze-function expected not only the function name but the parameters as well for C++ code (I know it's for overload stuff but it's so inconvenient.) It's even worse because it matched in a verbatim manner, where it's whitespace sensitive.
I'm thinking of cleaning this up now.

652

+1

RithikSharma marked 4 inline comments as done.Jul 8 2021, 9:32 AM
RithikSharma added inline comments.
clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
119–121

This sounds great, I have updated the patch.

226–243

Thanks, this time I moved all the code in a function, to make it more easier.

652

Makes sense to me, thanks.

RithikSharma marked 2 inline comments as done.Jul 8 2021, 9:32 AM
NoQ added a comment.Jul 8 2021, 5:16 PM

Looks good except one possible bug.

clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
192

I don't think we need an extra \n here. This would print an indefinite number of newlines every time -analyzer-stats is requested.

RithikSharma marked an inline comment as done.
RithikSharma added inline comments.
clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
192

Thanks, I've updated the patch.

NoQ added a comment.Jul 9 2021, 1:59 AM

Code looks great now!

One last thing, can you also add a tiny test to this patch? We already have a tiny explicit test for -analyzer-display-progress itself test/Analysis/analyzer-display-progress.cpp. It keeps passing because FileCheck matches sub-strings rather than entire strings. So you could extend it to say something like

// CHECK: analyzer-display-progress.cpp f() : {{[0-9]+}}ms
RithikSharma marked an inline comment as done.

Thanks, it was essential. I have updated the patch.

steakhal added inline comments.Jul 9 2021, 9:06 AM
clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
226–243

nvm it turns out that the opposite is true. Sorry for spamming here.
It seems like the display-progress prints the right string representation and the crash dump is flawed.
D105708 will resolve this inconvenience.

673–686

I think we could unconditionally record the execution time but conditionally display it.
It would make it possible to make the start time const and initialize it properly.
The time spent on the worklist algorithm should dominate this regardless.

As a general note, I prefer not to modify a variable unless I have a good reason to do so.
I think you could simply pass the ExprEngineEndTime - ExprEngineStartTime expression as the parameter for DisplayTime().

The same applies to the syntax timer as well.

NoQ accepted this revision.Jul 9 2021, 10:25 AM

Thanks a lot! I think this patch is good to land as-is.

clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
673–686

I think you could simply pass the ExprEngineEndTime - ExprEngineStartTime expression as the parameter for DisplayTime().

There's no overloaded operator-() on llvm::TimeRecord :(

I think there should be. Maybe we could make another patch about it.

clang/test/Analysis/analyzer-display-progress.cpp
23–30

ms! :)

This revision is now accepted and ready to land.Jul 9 2021, 10:25 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2021, 9:55 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript