[Bug other/92396] -ftime-trace support

[Bug other/92396] -ftime-trace support

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 48943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48943&action=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

[amonakov at gcc dot gnu.org]

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.

[Bug other/92396] -ftime-trace support

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
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

[jeremycong at gmail dot com]

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug other/92396] -ftime-trace support

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |---

[Bug other/92396] -ftime-trace support

[jules at penuchot dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

Jules Pénuchot <jules at penuchot dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jules at penuchot dot com

--- Comment #10 from Jules Pénuchot <jules at penuchot dot com> ---
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

[barry.revzin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

Barry Revzin <barry.revzin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barry.revzin at gmail dot com

--- Comment #11 from Barry Revzin <barry.revzin at gmail dot com> ---
+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

[hiraditya at msn dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396

AK <hiraditya at msn dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hiraditya at msn dot com

--- Comment #12 from AK <hiraditya at msn dot com> ---
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?