| Message ID | 20180508151413.GB16916@kam.mff.cuni.cz |
|---|---|
| State | New |
| Headers | show |
| Series | Incremental LTO linking part 2: lto-plugin support | expand |
On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > Hi, > with lto, incremental linking can be meaninfuly done in three ways: > 1) read LTO file and produce non-LTO .o file > this is current behaviour of gcc -r or ld -r with plugin > 2) read LTO files and merge section for later LTO > this is current behaviour of ld -r w/o plugin > 3) read LTO files into the compiler, link them and produce > incrementaly linked LTO object. > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes > and perhaps in order to have tool to turn LTO object into real object, we want > to have 1) available as well. GCC currently have -flinker-output option that > decides between modes that is decided by linker plugin and can be overwritten > by user (I have forgot to document this). > > I am targeting for -flinker-output=rel to be incremental linking into LTO > and adding -flinker-output=nolto-rel for 1). > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO > object files theger. For 2 HJ's binutils patchset has support and I think > it can be extended to handle 3 as well. But with default binutils we want > to warn users. This patch implements the warning (and prevents linker plugin > to add redundat linker-ouptut options. My users/hjl/lto-mixed/master branch is quite flexible. I can extend it if needed.
> On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > > Hi, > > with lto, incremental linking can be meaninfuly done in three ways: > > 1) read LTO file and produce non-LTO .o file > > this is current behaviour of gcc -r or ld -r with plugin > > 2) read LTO files and merge section for later LTO > > this is current behaviour of ld -r w/o plugin > > 3) read LTO files into the compiler, link them and produce > > incrementaly linked LTO object. > > > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes > > and perhaps in order to have tool to turn LTO object into real object, we want > > to have 1) available as well. GCC currently have -flinker-output option that > > decides between modes that is decided by linker plugin and can be overwritten > > by user (I have forgot to document this). > > > > I am targeting for -flinker-output=rel to be incremental linking into LTO > > and adding -flinker-output=nolto-rel for 1). > > > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO > > object files theger. For 2 HJ's binutils patchset has support and I think > > it can be extended to handle 3 as well. But with default binutils we want > > to warn users. This patch implements the warning (and prevents linker plugin > > to add redundat linker-ouptut options. > > > My users/hjl/lto-mixed/master branch is quite flexible. I can extend > it if needed. I think once the main patchset settles down we could add a way to communicate to lto-plugin if combined lto+non-lto .o files are supported by linker and sillence the warning. Honza > > -- > H.J.
On Tue, 8 May 2018, Jan Hubicka wrote: > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > > > Hi, > > > with lto, incremental linking can be meaninfuly done in three ways: > > > 1) read LTO file and produce non-LTO .o file > > > this is current behaviour of gcc -r or ld -r with plugin > > > 2) read LTO files and merge section for later LTO > > > this is current behaviour of ld -r w/o plugin > > > 3) read LTO files into the compiler, link them and produce > > > incrementaly linked LTO object. > > > > > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes > > > and perhaps in order to have tool to turn LTO object into real object, we want > > > to have 1) available as well. GCC currently have -flinker-output option that > > > decides between modes that is decided by linker plugin and can be overwritten > > > by user (I have forgot to document this). > > > > > > I am targeting for -flinker-output=rel to be incremental linking into LTO > > > and adding -flinker-output=nolto-rel for 1). > > > > > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO > > > object files theger. For 2 HJ's binutils patchset has support and I think > > > it can be extended to handle 3 as well. But with default binutils we want > > > to warn users. This patch implements the warning (and prevents linker plugin > > > to add redundat linker-ouptut options. > > > > > > My users/hjl/lto-mixed/master branch is quite flexible. I can extend > > it if needed. > > I think once the main patchset settles down we could add a way to communicate > to lto-plugin if combined lto+non-lto .o files are supported by linker and sillence > the warning. How does the patchset deal with partially linking fat objects? How do HJs binutils deal with them when you consider a fat object partially linked with a non-LTO object? Richard.
> On Tue, 8 May 2018, Jan Hubicka wrote: > > > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote: > > > > Hi, > > > > with lto, incremental linking can be meaninfuly done in three ways: > > > > 1) read LTO file and produce non-LTO .o file > > > > this is current behaviour of gcc -r or ld -r with plugin > > > > 2) read LTO files and merge section for later LTO > > > > this is current behaviour of ld -r w/o plugin > > > > 3) read LTO files into the compiler, link them and produce > > > > incrementaly linked LTO object. > > > > > > > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes > > > > and perhaps in order to have tool to turn LTO object into real object, we want > > > > to have 1) available as well. GCC currently have -flinker-output option that > > > > decides between modes that is decided by linker plugin and can be overwritten > > > > by user (I have forgot to document this). > > > > > > > > I am targeting for -flinker-output=rel to be incremental linking into LTO > > > > and adding -flinker-output=nolto-rel for 1). > > > > > > > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO > > > > object files theger. For 2 HJ's binutils patchset has support and I think > > > > it can be extended to handle 3 as well. But with default binutils we want > > > > to warn users. This patch implements the warning (and prevents linker plugin > > > > to add redundat linker-ouptut options. > > > > > > > > > My users/hjl/lto-mixed/master branch is quite flexible. I can extend > > > it if needed. > > > > I think once the main patchset settles down we could add a way to communicate > > to lto-plugin if combined lto+non-lto .o files are supported by linker and sillence > > the warning. > > How does the patchset deal with partially linking fat objects? How Currently it will turn them into slim LTO merged object. I can add code path that will optimize them into binary. That will be additional fun because we probably want to WPA them, but it should not be that hard to implement: WPA will produce one object file with merged LTO data that will be passed to linker plus partitions that will be turned to final binary. > do HJs binutils deal with them when you consider a fat object partially > linked with a non-LTO object? HJ? Honza > > Richard. > > -- > Richard Biener <rguenther@suse.de> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
On Wed, May 9, 2018 at 1:25 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> On Tue, 8 May 2018, Jan Hubicka wrote: >> >> > > On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote: >> > > > Hi, >> > > > with lto, incremental linking can be meaninfuly done in three ways: >> > > > 1) read LTO file and produce non-LTO .o file >> > > > this is current behaviour of gcc -r or ld -r with plugin >> > > > 2) read LTO files and merge section for later LTO >> > > > this is current behaviour of ld -r w/o plugin >> > > > 3) read LTO files into the compiler, link them and produce >> > > > incrementaly linked LTO object. >> > > > >> > > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes >> > > > and perhaps in order to have tool to turn LTO object into real object, we want >> > > > to have 1) available as well. GCC currently have -flinker-output option that >> > > > decides between modes that is decided by linker plugin and can be overwritten >> > > > by user (I have forgot to document this). >> > > > >> > > > I am targeting for -flinker-output=rel to be incremental linking into LTO >> > > > and adding -flinker-output=nolto-rel for 1). >> > > > >> > > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO >> > > > object files theger. For 2 HJ's binutils patchset has support and I think >> > > > it can be extended to handle 3 as well. But with default binutils we want >> > > > to warn users. This patch implements the warning (and prevents linker plugin >> > > > to add redundat linker-ouptut options. >> > > >> > > >> > > My users/hjl/lto-mixed/master branch is quite flexible. I can extend >> > > it if needed. >> > >> > I think once the main patchset settles down we could add a way to communicate >> > to lto-plugin if combined lto+non-lto .o files are supported by linker and sillence >> > the warning. >> >> How does the patchset deal with partially linking fat objects? How > > Currently it will turn them into slim LTO merged object. I can add code path > that will optimize them into binary. That will be additional fun because we probably > want to WPA them, but it should not be that hard to implement: WPA will produce one > object file with merged LTO data that will be passed to linker plus partitions that will > be turned to final binary. > >> do HJs binutils deal with them when you consider a fat object partially >> linked with a non-LTO object? > It should just work since the non-LTO object is stored in a special section. Linker can merge the special sections from multiple input files for ld -r. Let me know if you run into any issues.
On 05/08/2018 09:14 AM, Jan Hubicka wrote: > Hi, > with lto, incremental linking can be meaninfuly done in three ways: > 1) read LTO file and produce non-LTO .o file > this is current behaviour of gcc -r or ld -r with plugin > 2) read LTO files and merge section for later LTO > this is current behaviour of ld -r w/o plugin > 3) read LTO files into the compiler, link them and produce > incrementaly linked LTO object. > > 3 makes most sense and I am maing it new default for gcc -r. For testing purposes > and perhaps in order to have tool to turn LTO object into real object, we want > to have 1) available as well. GCC currently have -flinker-output option that > decides between modes that is decided by linker plugin and can be overwritten > by user (I have forgot to document this). > > I am targeting for -flinker-output=rel to be incremental linking into LTO > and adding -flinker-output=nolto-rel for 1). > > The main limitation of 2 and 3 is that you can not link LTO and non-LTO > object files theger. For 2 HJ's binutils patchset has support and I think > it can be extended to handle 3 as well. But with default binutils we want > to warn users. This patch implements the warning (and prevents linker plugin > to add redundat linker-ouptut options. This patch seems to have caused a lot of LTO tests in the G++ testsuite to fail on bare-metal targets because of the new warning. Here's a list for arm-none-eabi: FAIL: g++.dg/lto/20091002-1 cp_lto_20091002-1_0.o-cp_lto_20091002-1_0.o link, -fPIC -flto -Wno-return-type FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3 -flto FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto -std=c++11 FAIL: g++.dg/lto/pr65193 cp_lto_pr65193_0.o-cp_lto_pr65193_0.o link, -fPIC -r -nostdlib -flto -O2 -g -Wno-return-type FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11 FAIL: g++.dg/lto/pr65302 cp_lto_pr65302_0.o-cp_lto_pr65302_1.o link, -flto -O2 -Wno-return-type FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o-cp_lto_pr65316_1.o link, -flto -std=c++11 -g2 -fno-lto-odr-type-merging -O2 -Wno-return-type FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, -std=gnu++14 -flto -g -Wno-return-type FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, -std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type FAIL: g++.dg/lto/pr66180 cp_lto_pr66180_0.o-cp_lto_pr66180_1.o link, -flto -std=c++14 -r -nostdlib FAIL: g++.dg/lto/pr66705 cp_lto_pr66705_0.o-cp_lto_pr66705_0.o link, -O2 -flto -flto-partition=max -fipa-pta FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 -flto -fuse-linker-plugin FAIL: g++.dg/lto/pr69077 cp_lto_pr69077_0.o-cp_lto_pr69077_1.o link, -O3 -g -flto FAIL: g++.dg/lto/pr69133 cp_lto_pr69133_0.o-cp_lto_pr69133_1.o link, -flto -O2 FAIL: g++.dg/lto/pr69137 cp_lto_pr69137_0.o-cp_lto_pr69137_0.o link, -std=c++11 -g -flto FAIL: g++.dg/lto/pr79000 cp_lto_pr79000_0.o-cp_lto_pr79000_1.o link, -flto -g FAIL: g++.dg/lto/pr81940 cp_lto_pr81940_0.o-cp_lto_pr81940_0.o link, -O -flto FAIL: g++.dg/lto/pr85176 cp_lto_pr85176_0.o-cp_lto_pr85176_0.o link, -flto -g1 I got a similar list on the csky-elf port I'm preparing for submission, but I didn't see any of these FAILs for csky-linux-gnu. LTO is a mysterious black box to me, but maybe it has something to do with linking with static vs shared libraries? Or some linker script issue? I see part 8 of this patch series touched a whole bunch of other test cases, but not these. -Sandra
> On 05/08/2018 09:14 AM, Jan Hubicka wrote: > >Hi, > >with lto, incremental linking can be meaninfuly done in three ways: > > 1) read LTO file and produce non-LTO .o file > > this is current behaviour of gcc -r or ld -r with plugin > > 2) read LTO files and merge section for later LTO > > this is current behaviour of ld -r w/o plugin > > 3) read LTO files into the compiler, link them and produce > > incrementaly linked LTO object. > > > >3 makes most sense and I am maing it new default for gcc -r. For testing purposes > >and perhaps in order to have tool to turn LTO object into real object, we want > >to have 1) available as well. GCC currently have -flinker-output option that > >decides between modes that is decided by linker plugin and can be overwritten > >by user (I have forgot to document this). > > > >I am targeting for -flinker-output=rel to be incremental linking into LTO > >and adding -flinker-output=nolto-rel for 1). > > > >The main limitation of 2 and 3 is that you can not link LTO and non-LTO > >object files theger. For 2 HJ's binutils patchset has support and I think > >it can be extended to handle 3 as well. But with default binutils we want > >to warn users. This patch implements the warning (and prevents linker plugin > >to add redundat linker-ouptut options. > > This patch seems to have caused a lot of LTO tests in the G++ testsuite to > fail on bare-metal targets because of the new warning. Here's a list for > arm-none-eabi: > > FAIL: g++.dg/lto/20091002-1 cp_lto_20091002-1_0.o-cp_lto_20091002-1_0.o > link, -fPIC -flto -Wno-return-type > FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3 > -flto > FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto > -std=c++11 > FAIL: g++.dg/lto/pr65193 cp_lto_pr65193_0.o-cp_lto_pr65193_0.o link, -fPIC > -r -nostdlib -flto -O2 -g -Wno-return-type > FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto > -O0 -std=c++11 > FAIL: g++.dg/lto/pr65302 cp_lto_pr65302_0.o-cp_lto_pr65302_1.o link, -flto > -O2 -Wno-return-type > FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o-cp_lto_pr65316_1.o link, -flto > -std=c++11 -g2 -fno-lto-odr-type-merging -O2 -Wno-return-type > FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, > -std=gnu++14 -flto -g -Wno-return-type > FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link, > -std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type > FAIL: g++.dg/lto/pr66180 cp_lto_pr66180_0.o-cp_lto_pr66180_1.o link, -flto > -std=c++14 -r -nostdlib > FAIL: g++.dg/lto/pr66705 cp_lto_pr66705_0.o-cp_lto_pr66705_0.o link, -O2 > -flto -flto-partition=max -fipa-pta > FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 > -flto -flto-partition=none -fuse-linker-plugin > FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 > -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects > FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0 > -flto -fuse-linker-plugin -fno-fat-lto-objects > FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2 > -flto -fuse-linker-plugin > FAIL: g++.dg/lto/pr69077 cp_lto_pr69077_0.o-cp_lto_pr69077_1.o link, -O3 -g > -flto > FAIL: g++.dg/lto/pr69133 cp_lto_pr69133_0.o-cp_lto_pr69133_1.o link, -flto > -O2 > FAIL: g++.dg/lto/pr69137 cp_lto_pr69137_0.o-cp_lto_pr69137_0.o link, > -std=c++11 -g -flto > FAIL: g++.dg/lto/pr79000 cp_lto_pr79000_0.o-cp_lto_pr79000_1.o link, -flto > -g > FAIL: g++.dg/lto/pr81940 cp_lto_pr81940_0.o-cp_lto_pr81940_0.o link, -O > -flto > FAIL: g++.dg/lto/pr85176 cp_lto_pr85176_0.o-cp_lto_pr85176_0.o link, -flto > -g1 > > I got a similar list on the csky-elf port I'm preparing for submission, but > I didn't see any of these FAILs for csky-linux-gnu. LTO is a mysterious > black box to me, but maybe it has something to do with linking with static > vs shared libraries? Or some linker script issue? I see part 8 of this > patch series touched a whole bunch of other test cases, but not these. I wonder what warning you get? There was PR about older binutils incorrectly complaining about object file needing a plugin when IR object file is passed after incremental link. I do not think there is a way to silence this warning from GCC side. We could use -flinker-output=nonlto-rel to avoid incremental linking in those tests but eventually we will want some test coverage :) Honza > > -Sandra
On 06/18/2018 02:45 AM, Jan Hubicka wrote: >> On 05/08/2018 09:14 AM, Jan Hubicka wrote: >>> Hi, >>> with lto, incremental linking can be meaninfuly done in three ways: >>> 1) read LTO file and produce non-LTO .o file >>> this is current behaviour of gcc -r or ld -r with plugin >>> 2) read LTO files and merge section for later LTO >>> this is current behaviour of ld -r w/o plugin >>> 3) read LTO files into the compiler, link them and produce >>> incrementaly linked LTO object. >>> >>> 3 makes most sense and I am maing it new default for gcc -r. For testing purposes >>> and perhaps in order to have tool to turn LTO object into real object, we want >>> to have 1) available as well. GCC currently have -flinker-output option that >>> decides between modes that is decided by linker plugin and can be overwritten >>> by user (I have forgot to document this). >>> >>> I am targeting for -flinker-output=rel to be incremental linking into LTO >>> and adding -flinker-output=nolto-rel for 1). >>> >>> The main limitation of 2 and 3 is that you can not link LTO and non-LTO >>> object files theger. For 2 HJ's binutils patchset has support and I think >>> it can be extended to handle 3 as well. But with default binutils we want >>> to warn users. This patch implements the warning (and prevents linker plugin >>> to add redundat linker-ouptut options. >> >> This patch seems to have caused a lot of LTO tests in the G++ testsuite to >> fail on bare-metal targets because of the new warning. >> [snip] > > I wonder what warning you get? There was PR about older binutils incorrectly > complaining about object file needing a plugin when IR object file is passed > after incremental link. > I do not think there is a way to silence this warning from GCC side. > We could use -flinker-output=nonlto-rel to avoid incremental linking in those > tests but eventually we will want some test coverage :) It is exactly the warning newly added by this patch. /scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld: warning: incremental linking of LTO and non-LTO objects; using -flinker-output=nolto-rel which will bypass whole program optimization I built a completely fresh arm-none-eabi toolchain with a brand-new binutils-gdb trunk checkout, so this isn't a problem with an old binutils. -Sandra
> > It is exactly the warning newly added by this patch. > > /scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld: > warning: incremental linking of LTO and non-LTO objects; using > -flinker-output=nolto-rel which will bypass whole program optimization > > I built a completely fresh arm-none-eabi toolchain with a brand-new > binutils-gdb trunk checkout, so this isn't a problem with an old binutils. This is different issue. Perhaps it is because we normaly link in shared lib but now we bring -fno-lto object into LTO incremental link. What object files are being linked together here? Honza > > -Sandra
On 06/18/2018 11:37 AM, Jan Hubicka wrote: >> >> It is exactly the warning newly added by this patch. >> >> /scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld: >> warning: incremental linking of LTO and non-LTO objects; using >> -flinker-output=nolto-rel which will bypass whole program optimization >> >> I built a completely fresh arm-none-eabi toolchain with a brand-new >> binutils-gdb trunk checkout, so this isn't a problem with an old binutils. > > This is different issue. Perhaps it is because we normaly link in shared lib but now > we bring -fno-lto object into LTO incremental link. > What object files are being linked together here? The exact commands being used to build one of the test cases are: arm-none-eabi-g++ -fno-diagnostics-show-caret -fdiagnostics-color=never -fmessage-length=0 -fPIC -flto -Wno-return-type -c -o cp_lto_20091002-1_0.o /scratch/sandra/arm-eabi-upstream/src/gcc-mainline/gcc/testsuite/g++.dg/lto/20091002-1_0.C arm-none-eabi-g++ cp_lto_20091002-1_0.o g++_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -fmessage-length=0 -fPIC -flto -Wno-return-type -fPIC -r -nostdlib -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -o g++-dg-lto-20091002-1-01.exe The target here is the GDB ARM simulator, BTW. -Sandra
Index: lto-plugin.c =================================================================== --- lto-plugin.c (revision 260042) +++ lto-plugin.c (working copy) @@ -27,10 +27,13 @@ More information at http://gcc.gnu.org/wiki/whopr/driver. This plugin should be passed the lto-wrapper options and will forward them. - It also has 2 options of its own: + It also has options at his own: -debug: Print the command line used to run lto-wrapper. -nop: Instead of running lto-wrapper, pass the original to the plugin. This - only works if the input files are hybrid. */ + only works if the input files are hybrid. + -linker-output-known: Do not determine linker output + -sym-style={none,win32,underscore|uscore} + -pass-through */ #ifdef HAVE_CONFIG_H #include "config.h" @@ -159,6 +162,7 @@ static struct plugin_file_info *claimed_files = NULL; static unsigned int num_claimed_files = 0; +static unsigned int non_claimed_files = 0; /* List of files with offloading. */ static struct plugin_offload_file *offload_files; @@ -185,6 +189,7 @@ static char *resolution_file = NULL; static enum ld_plugin_output_file_type linker_output; static int linker_output_set; +static int linker_output_known; /* The version of gold being used, or -1 if not gold. The number is MAJOR * 100 + MINOR. */ @@ -637,7 +642,8 @@ all_symbols_read_handler (void) { unsigned i; - unsigned num_lto_args = num_claimed_files + lto_wrapper_num_args + 3; + unsigned num_lto_args = num_claimed_files + lto_wrapper_num_args + 2 + + !linker_output_known; char **lto_argv; const char *linker_output_str = NULL; const char **lto_arg_ptr; @@ -661,26 +667,37 @@ for (i = 0; i < lto_wrapper_num_args; i++) *lto_arg_ptr++ = lto_wrapper_argv[i]; - assert (linker_output_set); - switch (linker_output) + if (!linker_output_known) { - case LDPO_REL: - linker_output_str = "-flinker-output=rel"; - break; - case LDPO_DYN: - linker_output_str = "-flinker-output=dyn"; - break; - case LDPO_PIE: - linker_output_str = "-flinker-output=pie"; - break; - case LDPO_EXEC: - linker_output_str = "-flinker-output=exec"; - break; - default: - message (LDPL_FATAL, "unsupported linker output %i", linker_output); - break; + assert (linker_output_set); + switch (linker_output) + { + case LDPO_REL: + if (non_claimed_files) + { + message (LDPL_WARNING, "incremental linking of LTO and non-LTO " + "objects; using -flinker-output=nolto-rel which will " + "bypass whole program optimization"); + linker_output_str = "-flinker-output=nolto-rel"; + } + else + linker_output_str = "-flinker-output=rel"; + break; + case LDPO_DYN: + linker_output_str = "-flinker-output=dyn"; + break; + case LDPO_PIE: + linker_output_str = "-flinker-output=pie"; + break; + case LDPO_EXEC: + linker_output_str = "-flinker-output=exec"; + break; + default: + message (LDPL_FATAL, "unsupported linker output %i", linker_output); + break; + } + *lto_arg_ptr++ = xstrdup (linker_output_str); } - *lto_arg_ptr++ = xstrdup (linker_output_str); if (num_offload_files > 0) { @@ -1108,6 +1125,7 @@ goto cleanup; err: + non_claimed_files++; free (lto_file.name); cleanup: @@ -1122,6 +1140,8 @@ static void process_option (const char *option) { + if (strcmp (option, "-linker-output-known") == 0) + linker_output_known = 1; if (strcmp (option, "-debug") == 0) debug = 1; else if (strcmp (option, "-nop") == 0)
Hi, with lto, incremental linking can be meaninfuly done in three ways: 1) read LTO file and produce non-LTO .o file this is current behaviour of gcc -r or ld -r with plugin 2) read LTO files and merge section for later LTO this is current behaviour of ld -r w/o plugin 3) read LTO files into the compiler, link them and produce incrementaly linked LTO object. 3 makes most sense and I am maing it new default for gcc -r. For testing purposes and perhaps in order to have tool to turn LTO object into real object, we want to have 1) available as well. GCC currently have -flinker-output option that decides between modes that is decided by linker plugin and can be overwritten by user (I have forgot to document this). I am targeting for -flinker-output=rel to be incremental linking into LTO and adding -flinker-output=nolto-rel for 1). The main limitation of 2 and 3 is that you can not link LTO and non-LTO object files theger. For 2 HJ's binutils patchset has support and I think it can be extended to handle 3 as well. But with default binutils we want to warn users. This patch implements the warning (and prevents linker plugin to add redundat linker-ouptut options. Bootstrapped/regtested x86_64-linux with rest of the inclink patchset. OK? * lto-plugin.c: (non_claimed_files): New static var. (linker_ouput_known): New static var. (all_symbols_read_handler): When user specifies linker output do not imply it; output warning when nonlto-rel mode is forced. (claim_file_header): Record number of nonclaimed files. (process_option): Remember if linker output is known