From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99889 invoked by alias); 18 Jul 2019 16:13:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 99880 invoked by uid 89); 18 Jul 2019 16:13:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=captured X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 18 Jul 2019 16:13:40 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0169D30B1ACC; Thu, 18 Jul 2019 16:13:39 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-180.str.redhat.com [10.33.192.180]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 151065ED4A; Thu, 18 Jul 2019 16:13:37 +0000 (UTC) From: Florian Weimer To: Jeff Law Cc: Andi Kleen , Romain Geissler , gcc@gcc.gnu.org Subject: Re: Can LTO minor version be updated in backward compatible way ? References: <87ftn4in6x.fsf@linux.intel.com> <71c86eab-4178-e841-f968-b4425f851dd3@redhat.com> Date: Thu, 18 Jul 2019 16:13:00 -0000 Message-ID: <87ftn3z5fz.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00122.txt.bz2 * Jeff Law: > On 7/17/19 11:29 AM, Andi Kleen wrote: >> Romain Geissler 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. 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. > Right and stable LTO bytecode really isn't on the radar at this time. Maybe it's better to serialize the non-preprocessed source code instead. It would need some (hash-based?) deduplication. For #include directives, the hash of the file would be captured for reproducibility. Then if the initial #defines are known, the source code after processing can be reproduced exactly. Compressed source code is a surprisingly compact representation of a program, usually smaller than any (compressed) IR dump. Thanks, Florian