[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #12 from AK --- 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?
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Barry Revzin changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #11 from Barry Revzin --- +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.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Jules Pénuchot changed: What|Removed |Added CC||jules at penuchot dot com --- Comment #10 from Jules Pénuchot --- 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.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Richard Biener changed: What|Removed |Added Target Milestone|11.2|---
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Jakub Jelinek changed: What|Removed |Added Target Milestone|11.0|11.2 --- Comment #9 from Jakub Jelinek --- GCC 11.1 has been released, retargeting bugs to GCC 11.2.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 jeremycong at gmail dot com changed: What|Removed |Added CC||jeremycong at gmail dot com --- Comment #8 from jeremycong at gmail dot com --- 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.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #7 from Martin Liška --- 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.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Alexander Monakov --- 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.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 --- Comment #5 from Martin Liška --- Created attachment 48943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48943=edit 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?
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 --- Comment #4 from Trass3r --- Nice! Btw the traces can be viewed independently of the browser using https://www.speedscope.app.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-07 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Yes, I think we can do something similar to what clang does. I can work on that next stage1.
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (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...
[Bug other/92396] -ftime-trace support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- -ftime-report gets you some of that information. But this information is only really useful for the compiler developer.
