[cfe-dev] [RFC] Adding a different mode of "where clang spends time" reporting (timeline/flamegraph style)

[Justin Bogner via cfe-dev]

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
>> tightly?*
>>
>
> 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
> changed?

Changing LLVM interfaces and updating the uses in the monorepo is
sufficient. LLVM does not make any guarantees regarding stability of the
C++ APIs.

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:
> http://aras-p.info/blog/2019/01/21/Another-cool-MSVC-flag-d1reportTime/