public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions
@ 2023-11-27  0:35 zamazan4ik at tut dot by
  2023-11-27  0:44 ` [Bug gcov-profile/112717] " pinskia at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: zamazan4ik at tut dot by @ 2023-11-27  0:35 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 112717
           Summary: .gcda profiles compatibility guarantees between GCC
                    versions
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zamazan4ik at tut dot by
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi. I have several questions regarding .gcda profiles re-usage between GCC
versions for Profile-Guided Optimization (PGO) purposes.

The first question goes about forward and backward guarantees .gcda profiles. I
didn't find related information in the GCC documentation. Are there guarantees
in this area? Like "it's guaranteed that .gcda profiles from GCC version N will
be always readable by GCC version N+1", where N is a minor/major GCC version.
For us it's an important question since we are thinking about caching .gcda
profiles in storage so PGO profiles can be reused later probably with a newer
compiler. This goes in another direction too in the case if we generated the
PGO profile with GCC 10 and some time later decided to revert the compiler to
GCC 9. If there are some guarantees in this area, would be great to see them
documented somewhere in the documentation (probably in a place like
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html).

The second question is about PGO profiles reusability between GCC versions. As
far as I understand, PGO profiles track some "counters" about the code.
Possibly these counters can rely somehow on the performed by GCC optimizations
(it's just my guess). Let's imagine that GCC 11 added more optimization passes
that affect somehow generated code (e.g. much more aggressive inlining compared
to GCC 10). In this case, probably, PGO profiles from GCC 10 wouldn't be useful
anymore and we will need to regenerate them once again but with GCC 11. Is this
scenario real? If yes, are there ways to mitigate it somehow?

For LLVM I have the same questions that are discussed here:
https://discourse.llvm.org/t/profile-guided-optimization-pgo-related-questions-and-suggestions/75232
. As far as I understand, GCC also implements PGO on something like "IR" (don't
know how it's called properly in GCC - "Generic" or "GIMPLE"?), so probably
some answers from LLVM would be applicable to GCC as well.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions
  2023-11-27  0:35 [Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions zamazan4ik at tut dot by
@ 2023-11-27  0:44 ` pinskia at gcc dot gnu.org
  2023-11-27  0:45 ` sjames at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-11-27  0:44 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I thought this was documented but I don't see. There is no guarantee for
forward or backwards compatibility at all. In fact iirc there is a version
stored in the files to make sure the correct version is used with the version
of tools/compiler.

Plus not only different versions of the compiler changes profile data but also
different preprocessed sources could change the profile data (that even means
compiler options which change macros, e.g. -D* and even some -f/-m options
define some macros that could change the sources being processed).

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions
  2023-11-27  0:35 [Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions zamazan4ik at tut dot by
  2023-11-27  0:44 ` [Bug gcov-profile/112717] " pinskia at gcc dot gnu.org
@ 2023-11-27  0:45 ` sjames at gcc dot gnu.org
  2023-11-27  0:49 ` zamazan4ik at tut dot by
  2023-11-27  0:53 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: sjames at gcc dot gnu.org @ 2023-11-27  0:45 UTC (permalink / raw)
  To: gcc-bugs

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
Related but a different problem:
https://github.com/llvm/llvm-project/issues/52683.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions
  2023-11-27  0:35 [Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions zamazan4ik at tut dot by
  2023-11-27  0:44 ` [Bug gcov-profile/112717] " pinskia at gcc dot gnu.org
  2023-11-27  0:45 ` sjames at gcc dot gnu.org
@ 2023-11-27  0:49 ` zamazan4ik at tut dot by
  2023-11-27  0:53 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: zamazan4ik at tut dot by @ 2023-11-27  0:49 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Alexander Zaitsev <zamazan4ik at tut dot by> ---
> I thought this was documented but I don't see. There is no guarantee for forward or backwards compatibility at all. In fact iirc there is a version stored in the files to make sure the correct version is used with the version of tools/compiler.

Could we add this information to the documentation? Would be really helpful to
the users to know this detail.

Since your answer am I right that right now it's a strong
recommendation/requirement to regenerate PGO profiles with each GCC update?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gcov-profile/112717] .gcda profiles compatibility guarantees between GCC versions
  2023-11-27  0:35 [Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions zamazan4ik at tut dot by
                   ` (2 preceding siblings ...)
  2023-11-27  0:49 ` zamazan4ik at tut dot by
@ 2023-11-27  0:53 ` pinskia at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-11-27  0:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
My suggestion is only do profiling build right before release. And never store
the files in a repo at all. Any changes to the source base will cause the
profile to be wrong.

Maybe do it as part of a CI instead of storing around them.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-11-27  0:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-27  0:35 [Bug gcov-profile/112717] New: .gcda profiles compatibility guarantees between GCC versions zamazan4ik at tut dot by
2023-11-27  0:44 ` [Bug gcov-profile/112717] " pinskia at gcc dot gnu.org
2023-11-27  0:45 ` sjames at gcc dot gnu.org
2023-11-27  0:49 ` zamazan4ik at tut dot by
2023-11-27  0:53 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).