From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26543 invoked by alias); 21 Apr 2017 12:08:19 -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 26530 invoked by uid 89); 21 Apr 2017 12:08:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2804 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Apr 2017 12:08:17 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 75290AC04 for ; Fri, 21 Apr 2017 12:08:17 +0000 (UTC) Date: Fri, 21 Apr 2017 12:46:00 -0000 From: Richard Biener To: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR78847 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2017-04/txt/msg00945.txt.bz2 On Thu, 9 Feb 2017, Richard Biener wrote: > > The following patch fixes a missed optimization caused by niter analysis > returning a complex pointer subtraction expression instead of a constant > for a loop with a pointer IV (it looks like pointer IVs are quite common > in libstdc++). > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Not a regression (well, didn't try to find a release where we optimized > the testcase, but it needs c++14 library support anyway). I'm also > not quite sure associate_trees handles pointer types correctly > (there is some pointer type handling in the associate case but > POINTER_PLUS_EXPR folding for example does not dispatch to associate). > > I guess trying to add some more exhaustive testcases for GENERIC input > is required. I've generalized a bit and convinced myself it is safe. Bootstrapped and tested on x86_64-unknow-linux-gnu, applied to trunk. Richard. 2017-04-21 Richard Biener PR tree-optimization/78847 * fold-const.c (split_tree): Handle POINTER_PLUS_EXPR. * g++.dg/tree-ssa/pr78847.C: New testcase. Index: gcc/testsuite/g++.dg/tree-ssa/pr78847.C =================================================================== *** gcc/testsuite/g++.dg/tree-ssa/pr78847.C (nonexistent) --- gcc/testsuite/g++.dg/tree-ssa/pr78847.C (working copy) *************** *** 0 **** --- 1,26 ---- + /* { dg-do compile } */ + /* { dg-require-effective-target c++14 } */ + /* { dg-options "-O3 -fdump-tree-ldist" } */ + + #include + #include + #include + + using string_view = std::experimental::string_view; + + class Foo { + constexpr static size_t Length = 9; + char ascii_[Length]; + public: + Foo(); + string_view view() const { + return string_view(ascii_, Length); + } + }; + + void testWithLoopValue(const Foo foo, size_t ptr, char *buf_) { + for (auto c : foo.view()) + buf_[ptr++] = c; + } + + /* { dg-final { scan-tree-dump "memcpy\[^\n\r\]*, 9\\);" "ldist" } } */ Index: gcc/fold-const.c =================================================================== --- gcc/fold-const.c (revision 247049) +++ gcc/fold-const.c (working copy) @@ -798,8 +798,11 @@ split_tree (location_t loc, tree in, tre though the C standard doesn't say so) for integers because the value is not affected. For reals, the value might be affected, so we can't. */ - && ((code == PLUS_EXPR && TREE_CODE (in) == MINUS_EXPR) - || (code == MINUS_EXPR && TREE_CODE (in) == PLUS_EXPR)))) + && ((code == PLUS_EXPR && TREE_CODE (in) == POINTER_PLUS_EXPR) + || (code == PLUS_EXPR && TREE_CODE (in) == MINUS_EXPR) + || (code == MINUS_EXPR + && (TREE_CODE (in) == PLUS_EXPR + || TREE_CODE (in) == POINTER_PLUS_EXPR))))) { tree op0 = TREE_OPERAND (in, 0); tree op1 = TREE_OPERAND (in, 1);