From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199721-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 109532 invoked by alias); 18 Jul 2019 11:40:57 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 109514 invoked by uid 89); 18 Jul 2019 11:40:57 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: mail-lj1-f179.google.com
Received: from mail-lj1-f179.google.com (HELO mail-lj1-f179.google.com) (209.85.208.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Jul 2019 11:40:56 +0000
Received: by mail-lj1-f179.google.com with SMTP id x25so27025265ljh.2        for <gcc@gcc.gnu.org>; Thu, 18 Jul 2019 04:40:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:references:in-reply-to:from:date:message-id:subject:to         :cc;        bh=zgnOI1DRYYY7guj2OLdZQWv5W0WMeyyaRjpBtWNnWCI=;        b=f0vpzjYVHaVDYP50nsieGPbg1TLgNZdxDKwC99pv5EevvxLgayvZMEuu2uTwhUrZMD         v98kbW78qkU5ao0yqXoYSJfuN6Q0gPnuVZG5frM/3UaZWxV6mH1VAEPqrGcVt9EQTpUs         OlUFv0inBQkQLy8oz8a4MfRXPY4NNL0zO4uU6z6nbOi9rMiEiV/a9cScqzera06VwTH9         43JFIsL3t5JaAf4dKUwwxFmcv4VE7FWMPAgg/H3J5mtL1cNGtDHYiAShdQElKLoAVnAX         aSDvT+9C938TXNoMVG54PVV2wyOvlQidLL+NUY/RZLmn9r9+AF0CFgTp8RCxDSyvt4QC         8+cQ==
MIME-Version: 1.0
References: <alpine.LSU.2.20.1907171350160.51264@ncerndobedev5004.etv.nce.amadeus.net> <87ftn4in6x.fsf@linux.intel.com>
In-Reply-To: <87ftn4in6x.fsf@linux.intel.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Thu, 18 Jul 2019 11:40:00 -0000
Message-ID: <CAFiYyc1OYMBQ3ADLs6GuHp8YfegHTYQ7Lwj=Hwbf5Pk3cZNcbQ@mail.gmail.com>
Subject: Re: Can LTO minor version be updated in backward compatible way ?
To: Andi Kleen <ak@linux.intel.com>
Cc: Romain Geissler <romain.geissler@amadeus.com>, GCC Development <gcc@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2019-07/txt/msg00121.txt.bz2

On Wed, Jul 17, 2019 at 7:30 PM Andi Kleen <ak@linux.intel.com> wrote:
>
> Romain Geissler <romain.geissler@amadeus.com> writes:
> >
> > I have no idea of the LTO format and if indeed it can easily be updated
> > in a backward compatible way. But I would say it would be nice if it
> > could, and would allow adoption for projects spread on many teams
> > depending on each others and unable to re-build everything at each
> > toolchain update.
>
> Right now any change to an compiler option breaks the LTO format
> in subtle ways.

Indeed - that one is quite awkward.  I wonder if we could try mitigating
that by streaming some hash in front of the actual data for optimization/target
nodes we can verify is correct.  Such change would be local to
optc-save-gen.awk and materialize in cl_*_stream_{in,out}.

I think that's the only place where streaming is auto-generated.

Richard.

> In fact even the minor changes that are currently
> done are not frequent enough to catch all such cases.
>
> So it's unlikely to really work.
>
> -Andi
>