From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8218 invoked by alias); 13 Sep 2019 12:58:15 -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 8094 invoked by uid 89); 13 Sep 2019 12:58:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f45.google.com Received: from mail-lf1-f45.google.com (HELO mail-lf1-f45.google.com) (209.85.167.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Sep 2019 12:58:13 +0000 Received: by mail-lf1-f45.google.com with SMTP id c195so7174160lfg.9 for ; Fri, 13 Sep 2019 05:58:13 -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=XtKnMPQdSFGISZKS5S7isTOh5jCt0WfBe6dNXH+n0IU=; b=qLlXncv7JedVbORM5DeXekyonx9WCayWgOG80xQqFOOVaVJX+7VsUL/UrXNdP+/rWK 5/ksWKt8JFFHPIH2NWe+JzjTlhRzHC4zOUgeuJEHD4KidWU1X6t2PXLKwZPglr+6u2bu 2bufOGgx9gG6IHdsixqyEC2bQMAVx/74N5RCidQ+6Djq220vSzpw7BS0iywGbAwbIPhk ZTkvuyud73auFlfu/F6Ke6gu65xkLvVzpBeNZfxc/Zl3NuFHFixd7SCyPGNmr3pyoWr4 3XpJamHbbzEUr4ViqGVsDsHbk8VobTYBBoO6gkhP1KgT1jgl6bZjZQ5L+sayNi3BqCZ5 zyBw== MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 13 Sep 2019 12:58:00 -0000 Message-ID: Subject: Re: [EXT] Re: Questions about initialization data during LTO To: Gary Oblock Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00092.txt.bz2 On Thu, Sep 12, 2019 at 9:09 PM Gary Oblock wrote: > > On 9/12/19 3:12 AM, Richard Biener wrote: > > External Email > > > > ---------------------------------------------------------------------- > > On Thu, Sep 12, 2019 at 1:28 AM Gary Oblock wrote: > >> I'm trying to do a set of optimizations that drastically transform the > >> layout of arrays of structures. For obvious reasons they will need to > >> run at LTO time. I'm running into some difficulties comprehending how > >> the initialization data is stored. Also, I'm seeing DECL_INITIALs > >> being set to NULL and that is worrisome since it would throw a monkey > >> wrench into what I'm doing. That is, because for my optimizations to > >> work they will need to either disqualify an array with initialization > >> data or transform said data. > >> > >> So, is the initialization data being hidden at LTO time? > >> If not what's its format and how do I best manipulate it? > > You probably have to do at least part of the work at WPA time where > > DECL_INITIAL should be appropriately set. Initializers are generally only > > shipped to / output in one LTRANS unit unless they can be used for > > constant folding. > First, I thought WHOPR was deprecated?? On the contrary, it's the default. > Second, if the initializations > are stripped is there any indication that it's occurred? Third, is it > possible > to selectively disable the stripping for arrays of structures and > structures? As said, you need to view the whole program anyways so work at WPA time. That means all initializers are still present. > Note, this optimization is a lot harder to do as bits and pieces here and > there and perhaps totally unfeasible. I have to be able to examine all the > uses of of all the structures and all the variables of these types to in > order > to qualify the optimization. Then I have to do the same thing all over > again > to apply the transformations. Yes, indeed you have. Ideally you'd do function-level analysis at pre-WPA compile-time, then combine and decide how to transform at WPA time and actually apply the transform to the function bodies (and initializers) at LTRANS. > >> Any insight into how to deal with these problem would be most helpful. > >> These are some really interesting optimizations and will greatly speed > >> up code that uses large arrays of structures. > > Usually hinting the programmer is way easier here since a compiler has > > to give up too easily for data layout optimizations. Unless you only > > target specific benchmarks... > I don't follow you about hinting... Are you saying the programmer > would need to supply hints in the code enabling the optimizations? > I want to be as general as possible and improve "dusty decks" too. > Admittedly the first cut of these optimizations will be quite limited. > My plan is to get the framework to function and then extend it. No, the compiler should hint the programmer at "hey, if you'd reorder this performance would go up!" and have the programmer do the transform. Richard. > Gary > > > > Richard. > > > >> Thanks, > >> > >> Gary Oblock >