RE: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613974.html Thanks, Eugene -Original Message- From: Eugene Rozenfeld Sent: Tuesday, March 14, 2023 2:21 PM To: Jeff Law ; gcc-patches@gcc.gnu.org; Andi Kleen Subject: RE: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build Hi Jeff, I revived profile_merger tool in http://github.com/google/autofdo and re-worked the patch to merge profiles for compiling the libraries. Please take a look at the attached patch. Thanks, Eugene -Original Message- From: Jeff Law Sent: Tuesday, November 22, 2022 10:16 PM To: Eugene Rozenfeld ; gcc-patches@gcc.gnu.org; Andi Kleen Subject: Re: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build [You don't often get email from jeffreya...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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
Re: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build
On 3/14/23 15:21, Eugene Rozenfeld wrote: From 1808fe371ab5618b7c0ce22c0dbecdaf593e516d Mon Sep 17 00:00:00 2001 From: Eugene Rozenfeld Date: Mon, 21 Nov 2022 13:33:38 -0800 Subject: [PATCH] Fix autoprofiledbootstrap build 1. Fix gcov version 2. Merge perf data collected when compiling the compiler and runtime libraries 3. Fix documentation typo Tested on x86_64-pc-linux-gnu. gcc/ChangeLog: * Makefile.in: Define PROFILE_MERGER * Makefile.tpl: Define PROFILE_MERGER * c/Make-lang.in: Merge perf data collected when compiling cc1 and runtime libraries * cp/Make-lang.in: Merge perf data collected when compiling cc1plus and runtime libraries * lto/Make-lang.in: Merge perf data collected when compiling lto1 and runtime libraries * doc/install.texi: Fix documentation typo OK jeff
RE: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build
Hi Jeff, I revived profile_merger tool in http://github.com/google/autofdo and re-worked the patch to merge profiles for compiling the libraries. Please take a look at the attached patch. Thanks, Eugene -Original Message- From: Jeff Law Sent: Tuesday, November 22, 2022 10:16 PM To: Eugene Rozenfeld ; gcc-patches@gcc.gnu.org; Andi Kleen Subject: Re: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build [You don't often get email from jeffreya...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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 0001-Fix-autoprofiledbootstrap-build.patch Description: 0001-Fix-autoprofiledbootstrap-build.patch
RE: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build
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 Sent: Tuesday, November 22, 2022 12:01 PM To: Eugene Rozenfeld ; gcc-patches@gcc.gnu.org; Andi Kleen Subject: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build [You don't often get email from jeffreya...@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
Re: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build
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
