diff mbox series

Fix autoprofiledbootstrap build

Message ID CY5PR21MB3542F5D5271CA9CEEE3C4EF9910A9@CY5PR21MB3542.namprd21.prod.outlook.com
State New
Headers
Series Fix autoprofiledbootstrap build |

Commit Message

Eugene Rozenfeld Nov. 21, 2022, 9:57 p.m. UTC 
  1. Fix gcov version
2. Don't attempt to create an autoprofile file for cc1 since cc1plus
(not cc1) is not invoked when building cc1
3. Fix documentation typo

Tested on x86_64-pc-linux-gnu.

gcc/ChangeLog:

	* c/Make-lang.in: Don't attempt to create an autoprofile file for cc1
	* cp/Make-lang.in: Fix gcov version
	* lto/Make-lang.in: Fix gcov version
	* doc/install.texi: Fix documentation typo
---
 gcc/c/Make-lang.in   | 15 +--------------
 gcc/cp/Make-lang.in  |  2 +-
 gcc/doc/install.texi |  2 +-
 gcc/lto/Make-lang.in |  2 +-
 4 files changed, 4 insertions(+), 17 deletions(-)

Comments

Jeff Law Nov. 22, 2022, 8:01 p.m. UTC | #1 
On 11/21/22 14:57, Eugene Rozenfeld via Gcc-patches wrote:
> 1. Fix gcov version
> 2. Don't attempt to create an autoprofile file for cc1 since cc1plus
> (not cc1) is not invoked when building cc1
> 3. Fix documentation typo
>
> Tested on x86_64-pc-linux-gnu.
>
> gcc/ChangeLog:
>
> 	* c/Make-lang.in: Don't attempt to create an autoprofile file for cc1
> 	* cp/Make-lang.in: Fix gcov version
> 	* lto/Make-lang.in: Fix gcov version
> 	* doc/install.texi: Fix documentation typo

Just to be 100% sure.  While the compiler is built with cc1plus, various 
runtime libraries are still build with the C compiler and thus would use 
cc1.  AFAICT it looks like we don't try to build the runtime libraries 
to get any data about the behavior of the C compiler.  Can you confirm?


Assuming that's correct, this is fine for the trunk.


Thanks,

Jeff
Eugene Rozenfeld Nov. 22, 2022, 9:20 p.m. UTC | #2 
I took another look at this. We actually collect perf data when building the libraries. So, we have ./prev-gcc/perf.data, ./prev-libcpp/perf.data, ./prev-libiberty/perf.data, etc. But when creating gcov data for  -fauto-profile build of cc1plus or cc1 we only use ./prev-gcc/perf.data . So, a better solution would be either having a single perf.data for all builds (gcc and libraries) or merging perf.data files before attempting autostagefeedback. What would you recommend?

Thanks,

Eugene

-----Original Message-----
From: Jeff Law <jeffreyalaw@gmail.com> 
Sent: Tuesday, November 22, 2022 12:01 PM
To: Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com>; gcc-patches@gcc.gnu.org; Andi Kleen <ak@linux.intel.com>
Subject: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build

[You don't often get email from jeffreyalaw@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On 11/21/22 14:57, Eugene Rozenfeld via Gcc-patches wrote:
> 1. Fix gcov version
> 2. Don't attempt to create an autoprofile file for cc1 since cc1plus 
> (not cc1) is not invoked when building cc1 3. Fix documentation typo
>
> Tested on x86_64-pc-linux-gnu.
>
> gcc/ChangeLog:
>
>       * c/Make-lang.in: Don't attempt to create an autoprofile file for cc1
>       * cp/Make-lang.in: Fix gcov version
>       * lto/Make-lang.in: Fix gcov version
>       * doc/install.texi: Fix documentation typo

Just to be 100% sure.  While the compiler is built with cc1plus, various runtime libraries are still build with the C compiler and thus would use cc1.  AFAICT it looks like we don't try to build the runtime libraries to get any data about the behavior of the C compiler.  Can you confirm?


Assuming that's correct, this is fine for the trunk.


Thanks,

Jeff
Jeff Law Nov. 23, 2022, 6:15 a.m. UTC | #3 
On 11/22/22 14:20, Eugene Rozenfeld wrote:
> I took another look at this. We actually collect perf data when building the libraries. So, we have ./prev-gcc/perf.data, ./prev-libcpp/perf.data, ./prev-libiberty/perf.data, etc. But when creating gcov data for  -fauto-profile build of cc1plus or cc1 we only use ./prev-gcc/perf.data . So, a better solution would be either having a single perf.data for all builds (gcc and libraries) or merging perf.data files before attempting autostagefeedback. What would you recommend?

ISTM that if neither approach loses data, then they're functionally 
equivalent -- meaning that we can select whichever is easier to wire 
into our build system.

A single perf.data might serialize the build.  So perhaps separate, then 
merge right before autostagefeedback.


But I'm willing to go with whatever you think is best.

Jeff
diff mbox series

Patch

diff --git a/gcc/c/Make-lang.in b/gcc/c/Make-lang.in
index 9bd9c0ea123..ba33ec03bf0 100644
--- a/gcc/c/Make-lang.in
+++ b/gcc/c/Make-lang.in
@@ -62,12 +62,6 @@  c_OBJS = $(C_OBJS) cc1-checksum.o c/gccspec.o
 # Use strict warnings for this front end.
 c-warn = $(STRICT_WARN)
 
-ifeq ($(if $(wildcard ../stage_current),$(shell cat \
-  ../stage_current)),stageautofeedback)
-$(C_OBJS): ALL_COMPILERFLAGS += -fauto-profile=cc1.fda
-$(C_OBJS): cc1.fda
-endif
-
 # compute checksum over all object files and the options
 # re-use the checksum from the prev-final stage so it passes
 # the bootstrap comparison and allows comparing of the cc1 binary
@@ -88,9 +82,6 @@  cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS)
 	  cc1-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
 	@$(call LINK_PROGRESS,$(INDEX.c),end)
 
-cc1.fda: ../stage1-gcc/cc1$(exeext) ../prev-gcc/$(PERF_DATA)
-	$(CREATE_GCOV) -binary ../stage1-gcc/cc1$(exeext) -gcov cc1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
-
 #

 # Build hooks:
 
@@ -180,7 +171,6 @@  c.mostlyclean:
 	-rm -f cc1$(exeext)
 	-rm -f c/*$(objext)
 	-rm -f c/*$(coverageexts)
-	-rm -f cc1.fda
 c.clean:
 c.distclean:
 	-rm -f c/config.status c/Makefile
@@ -201,7 +191,4 @@  c.stageprofile: stageprofile-start
 	-mv c/*$(objext) stageprofile/c
 c.stagefeedback: stagefeedback-start
 	-mv c/*$(objext) stagefeedback/c
-c.autostageprofile: autostageprofile-start
-	-mv c/*$(objext) autostageprofile/c
-c.autostagefeedback: autostagefeedback-start
-	-mv c/*$(objext) autostagefeedback/c
+
diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
index 291835d326e..49e5cd66912 100644
--- a/gcc/cp/Make-lang.in
+++ b/gcc/cp/Make-lang.in
@@ -178,7 +178,7 @@  endif
 cp/name-lookup.o: $(srcdir)/cp/std-name-hint.h
 
 cc1plus.fda: ../stage1-gcc/cc1plus$(exeext) ../prev-gcc/$(PERF_DATA)
-	$(CREATE_GCOV) -binary ../stage1-gcc/cc1plus$(exeext) -gcov cc1plus.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
+	$(CREATE_GCOV) -binary ../stage1-gcc/cc1plus$(exeext) -gcov cc1plus.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 2
 
 #

 # Build hooks:
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index c1876f24a84..61a483bc410 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3059,7 +3059,7 @@  It is recommended to only use GCC for this.
 
 On Linux/x86_64 hosts with some restrictions (no virtualization) it is
 also possible to do autofdo build with @samp{make
-autoprofiledback}. This uses Linux perf to sample branches in the
+autoprofiledbootstrap}. This uses Linux perf to sample branches in the
 binary and then rebuild it with feedback derived from the profile.
 Linux perf and the @code{autofdo} toolkit needs to be installed for
 this.
diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index a2dcf0dfc12..3ee748489ac 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -106,7 +106,7 @@  $(LTO_DUMP_EXE): $(LTO_DUMP_OBJS) $(BACKEND) $(LIBDEPS) $(lto2.prev)
 lto/lto-dump.o: $(LTO_OBJS)
 
 lto1.fda: ../prev-gcc/lto1$(exeext) ../prev-gcc/$(PERF_DATA)
-	$(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
+	$(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 2
 
 # LTO testing is done as part of C/C++/Fortran etc. testing.
 check-lto: