From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-415423-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21222 invoked by alias); 25 Nov 2015 19:17:46 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 21212 invoked by uid 89); 25 Nov 2015 19:17:45 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: nikam.ms.mff.cuni.cz
Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Nov 2015 19:17:44 +0000
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)	id B7C4D543989; Wed, 25 Nov 2015 20:17:40 +0100 (CET)
Date: Wed, 25 Nov 2015 19:21:00 -0000
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
Message-ID: <20151125191740.GB5371@kam.mff.cuni.cz>
References: <20151125085912.GD58491@kam.mff.cuni.cz> <alpine.LSU.2.11.1511251155460.4884@t29.fhfr.qr> <CAMe9rOpqi6fM_g1uG2077D+7SrJ5QqBX8mxhPDbah2jQzSpquw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMe9rOpqi6fM_g1uG2077D+7SrJ5QqBX8mxhPDbah2jQzSpquw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-SW-Source: 2015-11/txt/msg03139.txt.bz2

> >
> > 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.