From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34235 invoked by alias); 29 Jul 2015 22:10:44 -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 34222 invoked by uid 89); 29 Jul 2015 22:10:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f173.google.com Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com) (209.85.192.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 29 Jul 2015 22:10:42 +0000 Received: by pdbbh15 with SMTP id bh15so12585598pdb.1 for ; Wed, 29 Jul 2015 15:10:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BbI7qjW9mFsnB5e5SrJcU3LWEKzGDO4vjSRjyihRlxs=; b=ILocxRffPOVLxyo/V7YVAyRghyfnjr1+Y0MGnEx+MvqWd3ei812To7PINkDMHuJZJI DVnvBfMnDwiVxKNUuyulUmcoYy7pVDOpTv6o9Du6qokdDo3CYHCEJPIGnoGKdgoT2GHc LOA5kLd2ujSTQ4aU0+g+Ks9/GI0v8khs0bCBzZccBviTHxKPZE+7y4EnnFPXiIo1EKgN BFJ74QnZxtX7TuC93oeWM6gtB497iY5EEmRVpT3ZwrKWL2wg/rWa5rDOotvBFY9LyWUn 3ZXGqa3Wy2U0GhCibK11j6E4yo/c9KyGp3dDQieE0R/MqLlRWffXSFOdBHCi5e5gFbhS i3gQ== X-Gm-Message-State: ALoCoQlDagezYflUWmjAqPf5v7/dPd3+ppXXYZhgYFS7A3nn1h0ruF5d2WwbU8jiXiC2LOfTThWI X-Received: by 10.70.36.136 with SMTP id q8mr100602607pdj.23.1438207840011; Wed, 29 Jul 2015 15:10:40 -0700 (PDT) Received: from [192.168.1.7] (ip70-176-202-128.ph.ph.cox.net. [70.176.202.128]) by smtp.googlemail.com with ESMTPSA id u16sm31627524pdl.71.2015.07.29.15.10.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2015 15:10:39 -0700 (PDT) Message-ID: <55B94F58.6030109@linaro.org> Date: Wed, 29 Jul 2015 22:38:00 -0000 From: Michael Collison User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Biener , Jeff Law CC: gcc Patches Subject: Re: [PATCH] Optimize certain end of loop conditions into min/max operation References: <55B5A884.4060105@linaro.org> <55B65A4B.3050705@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg02518.txt.bz2 Richard and Jeff, Any conclusion to this discussion? Is this okay in match.pd or would you like to see it implemented elsewhere? On 7/28/2015 12:41 AM, Richard Biener wrote: > On Mon, Jul 27, 2015 at 6:20 PM, Jeff Law wrote: >> On 07/27/2015 03:25 AM, Richard Biener wrote: >>> On Mon, Jul 27, 2015 at 5:41 AM, Michael Collison >>> wrote: >>>> This patch is designed to optimize end of loop conditions involving of >>>> the >>>> form >>>> i < x && i < y into i < min (x, y). Loop condition involving '>' are >>>> handled similarly using max(x,y). >>>> As an example: >>>> >>>> #define N 1024 >>>> >>>> int a[N], b[N], c[N]; >>>> >>>> void add (unsignedint m, unsignedint n) >>>> { >>>> unsignedint i, bound = (m < n) ? m : n; >>>> for (i = 0; i < m && i < n; ++i) >>>> a[i] = b[i] + c[i]; >>>> } >>>> >>>> >>>> Performed bootstrap and make check on: x86_64_unknown-linux-gnu, >>>> arm-linux-gnueabihf, and aarch64-linux-gnu. >>>> Okay for trunk? >>> >>> So this works only for && that has been lowered to non-CFG form >>> (I suppose phiopt would catch that? If not, ifcombine would be the >>> place to implement it I guess). >> phiopt is supposed to be generating MIN/MAX expressions for us. If it isn't >> it'd be good to see any testcases where it isn't. >> >> I think that raises a general question though. Does it make more sense to >> capture MIN/MAX (and others) in phiopt or in the match.pd framework? > match.pd is good for pattern recognition - patterns of fixed size. There are > cases that are done in fold-const.c for example that doesn't fit very well > and should be done as separate pass, like for example figuring out whether > an expression can be easily negated or whether there are sign-changes that > can be stripped. Basically all cases where fold currently recurses (unbound). > > The above case is a corner case I think - the number of && you can change > into (multiple) MIN/MAX is unbound but we might only care about the case > where there will be one MIN/MAX operation. > > Generally phiopt and other patterns that match the CFG are not yet well > supported by match.pd (though I outlined how matching PHI nodes when > facing (simplify (cond ...) ...) would be possible). > > So while putting something into match.pd is easy I'd like people to > think if doing the same thing elsewhere is better - that is, if this is really > a pattern transform operation or if you are just implementing a special-case > of a general transform as a pattern. > > Richard. > >> Jeff >>