-ftime-report gets you some of that information.  But this information is only really useful for the compiler developer.

(In reply to Andrew Pinski from comment #1)
> -ftime-report gets you some of that information.  But this information is
> only really useful for the compiler developer.

Since GCC already can output json for other stuff (diagnostics, I think?), it should be possible to combine the -ftime-report option with the json subsystems to get the -ftime-trace option described...

Yes, I think we can do something similar to what clang does.
I can work on that next stage1.

Nice! Btw the traces can be viewed independently of the browser using https://www.speedscope.app.

Created attachment 48943 [details]
Time trace prototype

So I've just created a prototype patch, but I don't see it much useful:
https://gist.github.com/marxin/dc4354696bc5bd76cdc1d2ecaa4ab060

The main problem is that in case of tree/RTL passes, we run each pass for each function. Which makes the report full of thin lines.
Thoughts?

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.

Thank you Alexander for the pointer. I've just read the article and I must confirm that compiler uses demand for something that we can't currently support easily. I'm leaving that unassigned.

Anecdotally, this would be an amazing feature to have. Since enabling time tracing in clang, I've been able to improve build times significantly for a project that uses templates, but with the GCC time report information, I can't seem to get GCC build times improved to the same degree. I definitely don't think this feature is strictly useful for only the compiler developer.

GCC 11.1 has been released, retargeting bugs to GCC 11.2.

I've been writing a compile-time benchmarking and analysis tool (https://github.com/JPenuchot/ctbench) to study the impact of C++ metaprogramming techniques on compile-times. Clang's time-trace features allows me to break the measurements down to every major compiler pass and get a better understanding of what's happening under the hood.

I'd be really happy if GCC provided similar profiling tools and draw conclusions that aren't valid just for Clang.

+1 to supporting this. gcc's existing -ftime-report is useful for being able to make statements like "gcc 11 is substantially more efficient at constraint satisfaction than gcc 10 was" (nice job, folks!) but it isn't very useful for being able to answer questions like "this translation unit takes 90 seconds to compile, how can I improve that?" Clang's -ftime-trace, on the other hand, gives me granular data per function -- which can help me determine what the hot spots are, etc.

I was building a giant file that takes around 100 minutes. The -ftime-report gave nothing useful to find out hotspots. It is also not clear what we are reporting here as there is no documentation for it in man gcc. The %ages don't add up to 100 and that makes it confusing.

I'm wondering if making this task a GSoC project will get more attention?

Heli Shah has submitted a patch for this here:
https://gcc.gnu.org/pipermail/gcc-patches/2026-May/715621.html