From: Jan Hubicka <hubicka@ucw.cz>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Richard Biener <rguenther@suse.de>, Jan Hubicka <hubicka@ucw.cz>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Andi Kleen <ak@linux.intel.com>,
Cary Coutant <ccoutant@google.com>,
Ian Lance Taylor <iant@google.com>
Subject: Re: [RFC] Getting LTO incremental linking work
Date: Wed, 25 Nov 2015 19:21:00 -0000 [thread overview]
Message-ID: <20151125191740.GB5371@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAMe9rOpqi6fM_g1uG2077D+7SrJ5QqBX8mxhPDbah2jQzSpquw@mail.gmail.com>
> >
> > Your patch means that Andis/HJs work is no longer needed and we can
> > drop the section suffixes again?
> >
> >
>
> There is a difference between "ld -r " and "gcc -r". "ld -r" may not
> perform any LTO.
Theoretically ld -r may look up for the linker plugin on it search path that will
in turn execute GCC to link the IL. It is not implemented though.
I am not proposing to drop the section based incremental linking code however.
In fact I never paid too much attention to incremental linking. What are the main
use cases? I know some build systems use it to reduce final linking time. What
are the other uses?
It is out of scope of this patch, but eventually it would be nice to teach LTO
optimizers to work incrementally: it is perfectly possible for optimizers to
do their execute methods just not do any decisions that need whole program (i.e.
inlining when size increases) and apply the changes to IL/re-earlyoptimize changed
functions and stream.
Honza
>
> --
> H.J.
next prev parent reply other threads:[~2015-11-25 19:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 9:04 Jan Hubicka
2015-11-25 11:19 ` Richard Biener
2015-11-25 15:45 ` H.J. Lu
2015-11-25 19:21 ` Jan Hubicka [this message]
2015-11-25 23:09 ` Jan Hubicka
2015-11-25 23:56 ` Jan Hubicka
2015-11-28 10:35 ` Tom de Vries
2015-11-28 12:03 ` Tom de Vries
2015-11-28 16:05 ` Ilya Verbin
2015-11-28 17:41 ` Tom de Vries
2015-11-29 21:15 ` Jan Hubicka
2015-11-25 18:54 ` Jan Hubicka
2015-11-26 10:15 ` Richard Biener
2015-11-26 20:30 ` Jan Hubicka
2015-11-25 23:59 ` Andi Kleen
2015-11-26 0:24 ` Andi Kleen
2015-11-26 0:54 ` Jan Hubicka
2015-11-26 1:55 ` Andi Kleen
2015-11-26 2:02 ` Jan Hubicka
2015-11-26 2:12 ` Andi Kleen
2015-11-26 6:33 ` Jan Hubicka
2015-11-26 10:33 ` Richard Biener
2016-03-16 17:33 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151125191740.GB5371@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=ak@linux.intel.com \
--cc=ccoutant@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=iant@google.com \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).