From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56974 invoked by alias); 13 May 2016 11:52:43 -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 56931 invoked by uid 89); 13 May 2016 11:52:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=2680,6, 26806, _not_, scalarized X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 13 May 2016 11:52:32 +0000 Received: by mail-wm0-f67.google.com with SMTP id e201so3214051wme.2 for ; Fri, 13 May 2016 04:52:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QPOXAdv4Jefg3FH9d0JN9aHVKkt15EQyFEOJ9evrVHY=; b=ETAmr/iYlpLkl1tST/hgr1uf7OKZPDgU5YDdItlNtSEI7YtpuHNXkL+jKboTDGcKhh 21xnX1nkOJSm8TTNB5EAdkHxP4E7Abz/YyeyynXbDQ4UP/XZcjMcnRNUXik7lp2J+7HS xvQsZ90jzcBHeebLhjj3IzjB81sO6CoIVMda7yn5KLebjGe6657/6wekH/QuQFrPEz9+ Do1z+/48Yic3vJAHNbLyVyYMKVfpcddo1BVnpOch3LLNtz22PRmGkZQ5plxVyt48HS/a 225cdMvUfGVjXFkrthzMRpwKM/8uKF1YZf7K7ycpH9RCkDEpwtCDIZSKbIBkKIq1uhJ/ XpUQ== X-Gm-Message-State: AOPr4FX5IxRu4kaGX/dWzSAhH+chdQcaTANRvNFM/ZAmBg6aDFNpyeb5JgBV/yvtxuvbOmdjM28rTpY0+YJA4w== MIME-Version: 1.0 X-Received: by 10.194.134.170 with SMTP id pl10mr14818057wjb.88.1463140349529; Fri, 13 May 2016 04:52:29 -0700 (PDT) Received: by 10.194.33.196 with HTTP; Fri, 13 May 2016 04:52:29 -0700 (PDT) In-Reply-To: <20609673.FxQTIz62nb@polaris> References: <6226269.FBBDIS7nhY@polaris> <20609673.FxQTIz62nb@polaris> Date: Fri, 13 May 2016 11:52:00 -0000 Message-ID: Subject: Re: [patch] Fix PR tree-optimization/70884 From: Richard Biener To: Eric Botcazou Cc: GCC Patches , alan.lawrence@arm.com, Martin Jambor Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00964.txt.bz2 On Fri, May 13, 2016 at 1:01 PM, Eric Botcazou wrote: >> Hmm, the patch looks obvious if it was the intent to allow constant >> pool replacements >> _not_ only when the whole constant pool entry may go away. But I >> think the intent was >> to not do this otherwise it will generate worse code by forcing all >> loads from the constant pool to appear at >> function start. > > Do you mean when the whole constant pool entry is scalarized as opposed to > partially scalarized? When we scalarized all constant pool accesses (even if it is not fully accessed). The whole point was to be able to remove the constant pool entry later. At least if I remember correctly ... (it should in the end do what we now do at gimplification time but with better analysis on the cost/benefit). >> So - the "real" issue may be a missing >> should_scalarize_away_bitmap/cannot_scalarize_away_bitmap >> check somewhere. > > This seems to work: > > Index: tree-sra.c > =================================================================== > --- tree-sra.c (revision 236195) > +++ tree-sra.c (working copy) > @@ -2680,6 +2680,10 @@ analyze_all_variable_accesses (void) > EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi) > { > tree var = candidate (i); > + if (constant_decl_p (var) > + && (!bitmap_bit_p (should_scalarize_away_bitmap, i) > + || bitmap_bit_p (cannot_scalarize_away_bitmap, i))) > + continue; > struct access *access; > > access = sort_and_splice_var_accesses (var); > > but I have no idea whether this is correct or not. > > > Martin, are we sure to disable scalarization of constant_decl_p variables not > covered by initialize_constant_pool_replacements that way? Does the above "work"? Aka, not cause testsuite regressions? I remember the original patch was mostly for ARM (where we don't scalarize sth at gimplification time for some "cost" reason). Thanks, Richard. > -- > Eric Botcazou