* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
@ 2020-07-28 12:11 ` marxin at gcc dot gnu.org
2020-07-28 13:27 ` amonakov at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-07-28 12:11 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
2020-07-28 12:11 ` [Bug other/92396] -ftime-trace support marxin at gcc dot gnu.org
@ 2020-07-28 13:27 ` amonakov at gcc dot gnu.org
2020-07-29 7:21 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: amonakov at gcc dot gnu.org @ 2020-07-28 13:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
2020-07-28 12:11 ` [Bug other/92396] -ftime-trace support marxin at gcc dot gnu.org
2020-07-28 13:27 ` amonakov at gcc dot gnu.org
@ 2020-07-29 7:21 ` marxin at gcc dot gnu.org
2020-08-05 16:43 ` jeremycong at gmail dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-07-29 7:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-07-29 7:21 ` marxin at gcc dot gnu.org
@ 2020-08-05 16:43 ` jeremycong at gmail dot com
2021-04-27 11:38 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: jeremycong at gmail dot com @ 2020-08-05 16:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-08-05 16:43 ` jeremycong at gmail dot com
@ 2021-04-27 11:38 ` jakub at gcc dot gnu.org
2021-07-28 7:04 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-27 11:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2021-04-27 11:38 ` jakub at gcc dot gnu.org
@ 2021-07-28 7:04 ` rguenth at gcc dot gnu.org
2021-10-15 14:47 ` jules at penuchot dot com
` (2 subsequent siblings)
8 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-07-28 7:04 UTC (permalink / raw)
To: gcc-bugs
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 |---
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2021-07-28 7:04 ` rguenth at gcc dot gnu.org
@ 2021-10-15 14:47 ` jules at penuchot dot com
2022-03-29 16:47 ` barry.revzin at gmail dot com
2022-08-12 23:56 ` hiraditya at msn dot com
8 siblings, 0 replies; 9+ messages in thread
From: jules at penuchot dot com @ 2021-10-15 14:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2021-10-15 14:47 ` jules at penuchot dot com
@ 2022-03-29 16:47 ` barry.revzin at gmail dot com
2022-08-12 23:56 ` hiraditya at msn dot com
8 siblings, 0 replies; 9+ messages in thread
From: barry.revzin at gmail dot com @ 2022-03-29 16:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug other/92396] -ftime-trace support
[not found] <bug-92396-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2022-03-29 16:47 ` barry.revzin at gmail dot com
@ 2022-08-12 23:56 ` hiraditya at msn dot com
8 siblings, 0 replies; 9+ messages in thread
From: hiraditya at msn dot com @ 2022-08-12 23:56 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 9+ messages in thread