[PATCH] D43578: -ftime-report switch support in Clang

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Last time I looked at doing this, I found that LLVM's timer infrastructure was fundamentally unsuitable for adding timers like these to Clang. The big problems are that Clang switches between "layers" and pieces that should be independently accounted at a very large number of call sites (eg, there are hundreds of functions on Sema that the Parser calls), and that Clang makes heavy use of recursion and delegation between functions that we might want to time (and generally has a very complex call graph, matching the complexity of the grammars that it parses). Unless there have been major changes, none of that actually works in LLVM's timer infrastructure: the time allocated to recursive and mutually-recursive functions is misaccounted (double-counted or worse), and there's no real way to extract the amount of time spent parsing a particular kind of declaration without including all the time spent in nested subactions (such as instantiating unrelated templates, generating code, and so on) -- and even enumerating all the barriers between "time spent in parsing" and "time spent in semantic analysis" does not seem reasonable. Generating user-friendly but misleading and likely wrong timing data seems like it would be a big problem here.

So I don't think this patch is reasonable for that reason. I'm also not sure whether this, as is, is addressing a pressing use case -- for Clang developers, existing non-invasive profiling tools (such as linux-perftools) are likely to work a lot better for identifying where in the Clang source code we're spending time. And Clang users typically don't care which function we're in (unless they're filing a bug, where again a profiler is probably a better tool).

However, I do think we could make `-ftime-report` vastly more useful to Clang users. Specifically, I think the useful, actionable feedback we can give to users would be to tell them which parts of //their source code// are taking a long time to compile. Profiling information that can describe -- for instance -- the time spent instantiating the N slowest templates, or handling the N slowest functions, or evaluating the N slowest constant expressions, or parsing the N slowest `#include`d files, seems like it would be incredibly valuable. To make that work, I think we'll need to teach LLVM's timer infrastructure to properly separate out "self" time from "children" time for timers in the same group, and may need other infrastructure improvements.


https://reviews.llvm.org/D43578