https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
Alexander Monakov <amonakov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amonakov at gcc dot gnu.org
--- Comment #6 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Raw data from timevars is not suitable to make a useful-for-users -ftime-trace
report. The point of -ftime-trace is to present the person using the compiler
with a breakdown on the level of their source files, functions, template
instantiations, i.e. something they understand and can change. No need to show
users any sort of breakdown by individual GIMPLE/RTL passes: as far as they are
concerned it's one complex "code generation" phase they cannot substantially
change.
The original blog post by Aras Pranckevičius explains this well, contrasting
against GCC's and LLVM's -ftime-report:
https://aras-p.info/blog/2019/01/12/Investigating-compile-times-and-Clang-ftime-report/
(and part 2:
https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/
).
GCC simply doesn't measure time on the relevant "axes": we don't split
preprocessing time by included files, nor do we split template instantiation
time in the C++ frontend by template.
