From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51990 invoked by alias); 16 Jun 2017 13:31:31 -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 51978 invoked by uid 89); 16 Jun 2017 13:31:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ua0-f176.google.com Received: from mail-ua0-f176.google.com (HELO mail-ua0-f176.google.com) (209.85.217.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 13:31:30 +0000 Received: by mail-ua0-f176.google.com with SMTP id m31so25781067uam.1 for ; Fri, 16 Jun 2017 06:31:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DLk6fKAluAKY9MXa2REd821rLHYW88FABmrsRjDzE2A=; b=lM6mBegmPT4LrlmSokot/pibrzu1jog9yG5qm0n5vROMDfeLW8WCY3NjCAFwrUYY1n lpy0M8DIzX3iE4FdhfLQrEm/x1/rw8ZuNHyTEK7PgRP3xMSorwvQD08QGPxqeKbOkI8R uXg/MuAgPYT0bRb9Q2UDzFIn2hYOQC9LBhiyXPxZhpm6W9+dS031rBRWpq/H1HTRhOBA eiUUloApU+EWhponSf1P9uz+6i68F7pKYw1uO1bSzfxwm1KXy9YqQ/LKcqAji/JsibhB vAhEQ5k4aULfalwXVBU06f4nTQGnqSEb0BjhCqHpHiO6GDOOkzic6mAZ1p3aMolAdlLY KEdw== X-Gm-Message-State: AKS2vOwWZAwjWsHFMqAH91rrT0ztkQoE67VMj1gkuLMkDjUUGKuyese2 ZpK1Ao52H/yKxo6quXM6H2VN8q+1Og== X-Received: by 10.159.62.195 with SMTP id n3mr6709681uaj.144.1497619893071; Fri, 16 Jun 2017 06:31:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.47.19 with HTTP; Fri, 16 Jun 2017 06:31:32 -0700 (PDT) In-Reply-To: References: From: "Bin.Cheng" Date: Fri, 16 Jun 2017 13:31:00 -0000 Message-ID: Subject: Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split To: Richard Biener Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01192.txt.bz2 On Fri, Jun 16, 2017 at 2:10 PM, Richard Biener wrote: > On Fri, Jun 16, 2017 at 3:06 PM, Bin.Cheng wrote: >> On Fri, Jun 16, 2017 at 11:49 AM, Richard Biener >> wrote: >>> On Wed, Jun 14, 2017 at 3:07 PM, Bin Cheng wrote: >>>> Hi, >>>> Loop split forces intermediate computation to gimple operands all the time when >>>> computing bound information. This is not good since folding opportunities are >>>> missed. This patch fixes the issue by feeding all computation to folder and only >>>> forcing to gimple operand at last. >>>> >>>> Bootstrap and test on x86_64 and AArch64. Is it OK? >>> >>> Hm? It uses gimple_build () which should do the same as fold_buildN in terms >>> of simplification. >>> >>> So where does that not work? It is supposed to be the prefered way and no >>> new code should use force_gimple_operand (unless dealing with generic >>> coming from other middle-end infrastructure like SCEV or niter analysis) >> Hmm, current code calls force_gimpele operand several times which >> causes the inefficiency. The patch avoids that and does one call at >> the end. > > But it forces to the same sequence that is used for extending the expression > so folding should work. Where do you see that it does not? Note the > code uses gimple_build (), not gimple_build_assign (). In spec2k6/hmmer, when building fast_algorithms.c with below command line: ./gcc -Ofast -S fast_algorithms.c -o fast_algorithms.S -fdump-tree-all -fdump-tree-lsplit The lsplit dump contains: [12.75%]: _124 = _197 + 1; _123 = _124 + -1; _115 = MIN_EXPR <_197, _124>; Which is generated here. Thanks, bin > > Richard. > >> Thanks, >> bin >>> >>> Richard. >>> >>>> >>>> Thanks, >>>> bin >>>> 2017-06-12 Bin Cheng >>>> >>>> * tree-ssa-loop-split.c (compute_new_first_bound): Feed bound >>>> computation to folder, rather than force to gimple operands too >>>> early.