From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28926 invoked by alias); 30 Oct 2015 09:25:04 -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 28908 invoked by uid 89); 30 Oct 2015 09:25:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 30 Oct 2015 09:25:02 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40958) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Zs5vf-0008H2-Je for gcc-patches@gnu.org; Fri, 30 Oct 2015 05:24:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zs5ve-0006JQ-7E for gcc-patches@gnu.org; Fri, 30 Oct 2015 05:24:59 -0400 Received: from mail-yk0-x229.google.com ([2607:f8b0:4002:c07::229]:36743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs5ve-0006JM-3B for gcc-patches@gnu.org; Fri, 30 Oct 2015 05:24:58 -0400 Received: by ykba4 with SMTP id a4so69467155ykb.3 for ; Fri, 30 Oct 2015 02:24:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.49.211 with SMTP id x202mr5811135ywx.147.1446197097665; Fri, 30 Oct 2015 02:24:57 -0700 (PDT) Received: by 10.37.117.136 with HTTP; Fri, 30 Oct 2015 02:24:57 -0700 (PDT) In-Reply-To: <56333152.7040403@mentor.com> References: <5631F735.2080604@mentor.com> <56333152.7040403@mentor.com> Date: Fri, 30 Oct 2015 09:29:00 -0000 Message-ID: Subject: Re: [PATCH] Allow more pointer-plus folding From: Richard Biener To: Tom de Vries Cc: Jakub Jelinek , "gcc-patches@gnu.org" Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::229 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg03334.txt.bz2 On Fri, Oct 30, 2015 at 9:58 AM, Tom de Vries wrote: > [ was: Re: [PATCH] Don't handle CAST_RESTRICT (PR tree-optimization/49279) > ] > > On 29/10/15 12:38, Richard Biener wrote: >> >> On Thu, Oct 29, 2015 at 11:38 AM, Tom de Vries >> wrote: >>> >>> [ quote-pasted from >>> https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00464.html >>> ] >>> >>>> CAST_RESTRICT based disambiguation unfortunately isn't reliable, >>>> e.g. to store a non-restrict pointer into a restricted field, >>>> we add a non-useless cast to restricted pointer in the gimplifier, >>>> and while we don't consider that field to have a special restrict tag >>>> because it is unsafe to do so, we unfortunately create it for the >>>> CAST_RESTRICT before that and end up with different restrict tags >>>> for the same thing. See the PR for more details. >>>> >>>> This patch turns off CAST_RESTRICT handling for now, in the future >>>> we might try to replace it by explicit CAST_RESTRICT stmts in some form, >>>> but need to solve problems with multiple inlined copies of the same >>>> function >>>> with restrict arguments or restrict variables in it and intermixed code >>>> from >>>> them (or similarly code from different non-overlapping source blocks). >>>> >>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >>>> 4.6 too? >>>> >>>> 2011-10-06 Jakub Jelinek >>>> >>>> PR tree-optimization/49279 >>>> * tree-ssa-structalias.c (find_func_aliases): Don't handle >>>> CAST_RESTRICT. >>>> * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Allow >>>> restrict propagation. >>>> * tree-ssa.c (useless_type_conversion_p): Don't return false >>>> if TYPE_RESTRICT differs. >>>> >>>> * gcc.dg/tree-ssa/restrict-4.c: XFAIL. >>>> * gcc.c-torture/execute/pr49279.c: New test. >>> >>> >>> >>> Hi, >>> >>> In the patch adding support for CAST_RESTRICT ( >>> https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00176.html ) there was also >>> a >>> bit: >>> ... >>> * fold-const.c (fold_unary_loc): Don't optimize >>> POINTER_PLUS_EXPR casted to TYPE_RESTRICT pointer by >>> casting the inner pointer if it isn't TYPE_RESTRICT. >>> ... >>> which is still around. I suppose we can remove this bit as well. >>> >>> OK for trunk if bootstrap and reg-test succeeds? >> >> >> Ok. > > > Committed. > >> I think the checks on TREE_OPERAND (arg0, 1) are bogus though >> and either we should unconditionally sink the conversion or only >> if a conversion on TREE_OPERAND (arg0, 0) vanishes (I prefer the >> latter). >> > > Like this? OK for trunk if bootstrap/reg-test succeeds? Ok with using CONVERT_EXPR_P (TREE_OPERAND (arg0, 0)) instead of an explicit NOP_EXPR check. Thanks, Richard. > Thanks, > - Tom >