This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Incremental LTO linking part 2: lto-plugin support
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.
--
H.J.