From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79430 invoked by alias); 25 Jun 2019 14:15:58 -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 79350 invoked by uid 89); 25 Jun 2019 14:15:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:06d3a9f, H*f:sk:06d3a9f X-HELO: mail-lj1-f195.google.com Received: from mail-lj1-f195.google.com (HELO mail-lj1-f195.google.com) (209.85.208.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Jun 2019 14:15:55 +0000 Received: by mail-lj1-f195.google.com with SMTP id t28so16423334lje.9; Tue, 25 Jun 2019 07:15: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:content-transfer-encoding; bh=U2sDToYzNNd3aGHz/4uqGEwFWQK9vW+zJyPTd2GcjNg=; b=FxhruegUJO+SyvZ1gPXa2pnm3r8cBdXLzteenVpze2aiS+QhznBOXzd0tmIlvdERLy NWK0AY84qTNn0vb30tAV80KHT9Zd/ikjZ9mwqkEVQp8EvqZXxuvRAwvCiv7EPZJ6W11T bBJahOwLljSBVaal0qmKqBQ0DQICiQmSi+1Sue9zluADUkLkt6PqHeSGuTHYA/rmXdpv taD7BtH26ZEBwOfRUq3hOWmu6jOQsG4koKTHagyGjz8wA4DXc7aCvT4mnh8iZQZLYzOk RKc4hXEDu/+VQ1goLpFOcrIGPMPiA6wNL85p+yA8JJU9B5Xrjzl3yswDIJBTbDquhcJ3 cJTQ== MIME-Version: 1.0 References: <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> <20190621125718.qv2m5iygqj2b43fe@kam.mff.cuni.cz> <498ec44b-60ad-6f70-3c7a-b521f9fb6c56@suse.cz> <48330aa3-d678-89a1-aa86-09e948059733@suse.cz> <06d3a9f1-2d2a-8138-99d1-c6ad4fc4c020@suse.cz> In-Reply-To: <06d3a9f1-2d2a-8138-99d1-c6ad4fc4c020@suse.cz> From: Richard Biener Date: Tue, 25 Jun 2019 14:15: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/msg00302.txt.bz2 On Tue, Jun 25, 2019 at 10:14 AM Martin Li=C5=A1ka wrote: > > On 6/24/19 8:05 PM, Richard Biener wrote: > > On Mon, Jun 24, 2019 at 3:31 PM Martin Li=C5=A1ka wrot= e: > >> > >> On 6/24/19 2:44 PM, Richard Biener wrote: > >>> On Mon, Jun 24, 2019 at 2:12 PM Martin Li=C5=A1ka wr= ote: > >>>> > >>>> On 6/24/19 2:02 PM, Richard Biener wrote: > >>>>> On Fri, Jun 21, 2019 at 4:01 PM Martin Li=C5=A1ka = wrote: > >>>>>> > >>>>>> On 6/21/19 2:57 PM, Jan Hubicka wrote: > >>>>>>> This looks like good step (and please stream it in host independe= nt > >>>>>>> way). I suppose all these issues can be done one-by-one. > >>>>>> > >>>>>> So there's a working patch for that. However one will see followin= g errors > >>>>>> when using an older compiler or older LTO bytecode: > >>>>>> > >>>>>> $ gcc main9.o -flto > >>>>>> lto1: fatal error: bytecode stream in file =E2=80=98main9.o=E2=80= =99 generated with LTO version -25480.4493 instead of the expected 9.0 > >>>>>> > >>>>>> $ gcc main.o > >>>>>> lto1: internal compiler error: compressed stream: data error > >>>>> > >>>>> This is because of your change to bitfields or because with the old > >>>>> scheme the header with the > >>>>> version is compressed (is it?). > >>>> > >>>> Because currently also the header is compressed. > >>> > >>> That was it, yeah :/ Stupid decisions in the past. > >>> > >>> I guess we have to bite the bullet and do this kind of incompatible > >>> change, accepting > >>> the odd error message above. > >>> > >>>>> I'd simply avoid any layout changes > >>>>> in the version check range. > >>>> > >>>> Well, then we have to find out how to distinguish between compressio= n algorithms. > >>>> > >>>>> > >>>>>> To be honest, I would prefer the new .gnu.lto_.meta section. > >>>>>> Richi why is that so ugly? > >>>>> > >>>>> Because it's a change in the wrong direction and doesn't solve the > >>>>> issue we already > >>>>> have (cannot determine if a section is compressed or not). > >>>> > >>>> That's not true, the .gnu.lto_.meta section will be always uncompres= sed and we can > >>>> also backport changes to older compiler that can read it and print a= proper error > >>>> message about LTO bytecode version mismatch. > >>> > >>> We can always backport changes, yes, but I don't see why we have to. > >> > >> I'm fine with the backward compatibility break. But we should also con= sider lto-plugin.c > >> that is parsing following 2 sections: > >> > >> 91 #define LTO_SECTION_PREFIX ".gnu.lto_.symtab" > >> 92 #define LTO_SECTION_PREFIX_LEN (sizeof (LTO_SECTION_PREFIX) -= 1) > >> 93 #define OFFLOAD_SECTION ".gnu.offload_lto_.opts" > >> 94 #define OFFLOAD_SECTION_LEN (sizeof (OFFLOAD_SECTION) - 1) > > > > Yeah, I know. And BFD and gold hard-coded those __gnu_lto_{v1,slim} sy= mbols... > > Yep, they do, 'nm' is also using that. > > > > >>> > >>>>> ELF section overhead > >>>>> is quite big if you have lots of small functions. > >>>> > >>>> My patch is actually shrinking space as I'm suggesting to add _one_ = extra ELF section > >>>> and remove the section header from all other LTO sections. That will= save space > >>>> for all function sections. > >>> > >>> But we want the header there to at least say if the section is > >>> compressed or not. > >>> The fact that we have so many ELF section means we have the redundant= version > >>> info everywhere. > >>> > >>> We should have a single .gnu.lto_ section (and also get rid of those > >>> __gnu_lto_v1 and __gnu_lto_slim COMMON symbols - checking for > >>> existence of a symbol is more expensive compared to existence > >>> of a section). > >> > >> I like removal of the 2 aforementioned sections. To be honest I would = recommend to > >> add a new .gnu.lto_.meta section. > > > > Why .meta? Why not just .gnu.lto_? > > Works for me. > > > > >> We can use it instead of __gnu_lto_v1 and we can > >> have a flag there instead of __gnu_lto_slim. As a second step, I'm wil= ling to concatenate all > >> > >> LTO_section_function_body, > >> LTO_section_static_initializer > >> > >> sections into a single one. That will require an index that will have = to be created. I can discuss > >> that with Honza as he suggested using something smarter than function = names. > > > > I think the index belongs to symtab? > > > > Let's properly do it if we want to change it. Removing of > > __gnu_lto_v1/slim is going to be > > the most intrusive change btw. and orthogonal to the section changes. > > I'm fine with a proper change. So do I understand that correctly that: > - we'll come up with .gnu.lto_ section that will be used by bfd, gold and= nm > to detect LTO objects > - for some time, we'll keep __gnu_lto_v1 and __gnu_lto_slim for backward > compatibility with older binutils tool > - in couple of year, the legacy support will be removed Yep. Richard. > ? > > Martin > > > > > Richard. > > > >> > >> Thoughts? > >> Martin > >> > >>> > >>> Richard. > >>> > >>>> Martin > >>>> > >>>>> > >>>>> Richard. > >>>>> > >>>>>> > >>>>>> Martin > >>>> > >> >