[cfe-dev] [RFC] Adding a different mode of "where clang spends time" reporting (timeline/flamegraph style)
Justin Bogner via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 24 12:42:48 PST 2019
Aras Pranckevicius via cfe-dev <cfe-dev at lists.llvm.org> writes:
>> *I think the question is, "what next"? I don't really want to say "merge
>> it right away!", because then we will have two systems for generating time
>> reports, but I also don't want to send you off into the hills to refactor
>> the existing Timer to support both output formats, and then decide what to
>> do with all the fine-grained timers geared towards compiler developers.
>> Would you be interested in working in that that direction, or would you
>> rather hand the code off to someone else to try to integrate it more
> Good question.
> I could take a stab at trying to make some sort of "one implementation"
> that could both generate the old -ftime-report report, and a hierarchical
> timeline / flame chart style one. But I've never worked with llvm/clang
> codebase, so I'd have some questions! The major one is:
> - is it fine to change some interface (of e.g. Timer.h) and update all
> users inside LLVM monorepo to it? Or are there a million other projects
> using LLVM, with e.g. Timer.h being effectively an API that can't be
Changing LLVM interfaces and updating the uses in the monorepo is
sufficient. LLVM does not make any guarantees regarding stability of the
Feel free to ask as many questions as you need :)
> Alternatively, I could make the whole change be contained just within clang
> itself. Right now I have put the new timer under llvm Support library, but
> I only use it in one place within llvm; all other usages are from within
> Clang only. It could almost just as well be some timer thing that only
> Clang uses. Not sure if that's worth doing or is easier accepted, vs. "the
> rest of llvm would want a timeline timer utility too". Thoughts?
IMO Doing this work in llvm/Support makes the most sense, since it's
likely that frontends other than clang will benefit from this
functionality as well.
>> *I feel like right now C++ users don't have a lot of visibility into build
>> performance, so it ends up falling to specialist toolchain people to go and
>> debug these problems. If we made it easy to see into the performance of
>> compilation, it would democratize build time optimization, letting
>> generalists do these kinds of codebase cleanups. At least, I hope it will.
> Indeed. A lot of "optimize C++ codebase compile times" is viewed as black
> box, also with quite a lot of myths and cargo culting from the inernet.
> FWIW, Visual C++ has frontend timing report functionality too, but it was
> not documented at all. So I wrote about it a few days ago:
More information about the cfe-dev