From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63006 invoked by alias); 21 Jun 2019 12:34:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 62991 invoked by uid 89); 21 Jun 2019 12:34:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:ip*209.85.208.193, H*RU:209.85.208.193, HX-Spam-Relays-External:209.85.208.193, H*Ad:U*pinskia X-HELO: mail-lj1-f193.google.com Received: from mail-lj1-f193.google.com (HELO mail-lj1-f193.google.com) (209.85.208.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Jun 2019 12:34:52 +0000 Received: by mail-lj1-f193.google.com with SMTP id v18so5803013ljh.6; Fri, 21 Jun 2019 05:34:52 -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:content-transfer-encoding; bh=RsOE+Ioqf1KJ9l9uiau6Gz2oGGoA/M28KTDo2wJOM1g=; b=qAZYHWnRwneiWRvHxw6Zjqm9cWVAtaRrEjyvRkx48oILbMNHRqEI7p664HQbWY6nm4 pStUIk8XCY65xaiWFt1crmRfb/dVZo7cLjbK9o7HW5KeLdtlZBwAaZi6Fsju+yn3N0uI +sg4IjIWX52mL7/7JBBaWXI9ULQaf9efvoCNUm32vj2A+moGbnM5cshU+gEFvZMqa2SH lwUVnyUZEE0rA3vIE2tttanI0HOaU2KLa1qfEoRJOQ2tBpQEEfzNq9df+A3A+NwjhG8g NE19TQqMrlVR+nEyWMcyeHo5ff3Lj7uOdzGUK9ukNQrh5z1SCIeyQY6rn5emMAuxgPd7 D81w== MIME-Version: 1.0 References: <89e98dc0-e766-ffef-da0f-263c3b284e96@suse.cz> <1BBDAEDD-9432-4B12-BA20-63A6E047FDB6@gmail.com> <20190619192954.edwdfxns3gx2gt5m@kam.mff.cuni.cz> <122f53d2-5ae0-b801-81ab-36ce69f9efda@netcologne.de> <9417a329-c71c-4682-872c-60ff3524c47e@suse.cz> <20190620120225.s7ouywid2mntmhlm@kam.mff.cuni.cz> In-Reply-To: From: Richard Biener Date: Fri, 21 Jun 2019 12:34:00 -0000 Message-ID: Subject: Re: [PATCH] Add .gnu.lto_.meta section. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Jan Hubicka , Thomas Koenig , Andrew Pinski , Jeff Law , GCC Development , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg01299.txt.bz2 On Fri, Jun 21, 2019 at 12:20 PM Martin Li=C5=A1ka wrote: > > Hi. > > The patch is about a new ELF section that will contain information > about LTO version. And for the future, used compression will be stored > here. The patch removes streaming of the version into each section. I'd like each section to have a header containing a compression method (compressed or not, and now zlib vs. zstd). We currently have a mix and knowledge is hidden. I also remember I had old patches to make the data streamer compress the stream on-the-fly, not requiring the full uncompressed stream in memory and then re-access it for compression (needing more temporary memory). But IIRC the speedup was marginal. My thought is also that we should have exactly _one_ ELF section for the LTO bytecode and our own container inside (much like simple-object does for non-ELF). So having another one is, well, ugly ;) > Disadvantage is a format change that will lead to following errors when > LTO bytecode is used from a different version: > > $ gcc x.o > lto1: fatal error: bytecode stream in file =E2=80=98x.o=E2=80=99 generate= d with GCC compiler older than 10.0 > > $ gcc-9 main.o > lto1: fatal error: bytecode stream in file =E2=80=98main.o=E2=80=99 gener= ated with LTO version 850.0 instead of the expected 8.0 > > I've been testing the patch. > Thoughts? > Martin