From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105410 invoked by alias); 27 Apr 2017 15:45:27 -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 103419 invoked by uid 89); 27 Apr 2017 15:45:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=intention, principle, solid, cheap X-HELO: mail-ua0-f172.google.com Received: from mail-ua0-f172.google.com (HELO mail-ua0-f172.google.com) (209.85.217.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Apr 2017 15:45:23 +0000 Received: by mail-ua0-f172.google.com with SMTP id j59so22071011uad.0 for ; Thu, 27 Apr 2017 08:45:25 -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=QLfJZ/4To2caUUkpwCeOsPHtXC+w6U7u0Uc2axwQ6xw=; b=Zjqs2sKYgm4DfKC6Nb5XQvaGNupXfyvmkIGtnnXa3JKBKYgj4DK4z0N/aDcN2Qs500 GUb/a5BC571k5j/kPqHNUfiGZtBoAA6Ilj5JqP8pt52ebhR2w66BtKrarXzm2Uh7ZnFt ttRjq30GsE/hDK76z6zl5DLF5BXd2+zK0BLiYXWnknluI3a/w3wGSxLzztHV0wI+FFRp S0DHtd+8kSjQbni75c0dNWxnQ4+UB+VI+nOtu4ZpvbwhJSPoBe2aP5mJb92qAOk2vbUV yWiue/8VOtKuHzdieEav2y9riDWEszrx1xM9KScFvlVqpo3QHVvGmpLcF0eZvdmIBiZ8 F4gA== X-Gm-Message-State: AN3rC/7cNEq8507poLXJoBPvsg5NXytBYy2/fUX0WBasIPJ24IXkWUoA LClZj5DqGorPLHAp7IPgqoQg6QTjwg== X-Received: by 10.159.59.146 with SMTP id r18mr3390680uah.102.1493307923444; Thu, 27 Apr 2017 08:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.33.70 with HTTP; Thu, 27 Apr 2017 08:45:23 -0700 (PDT) In-Reply-To: <34eb71c0-0320-0515-d49c-1c05fe587d90@redhat.com> References: <34eb71c0-0320-0515-d49c-1c05fe587d90@redhat.com> From: "Bin.Cheng" Date: Thu, 27 Apr 2017 16:53:00 -0000 Message-ID: Subject: Re: [PATCH GCC8][14/33]Handle more cheap operations in force_expr_to_var_cost To: Jeff Law Cc: Richard Biener , Bin Cheng , "gcc-patches@gcc.gnu.org" , nd Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg01413.txt.bz2 On Thu, Apr 27, 2017 at 4:30 PM, Jeff Law wrote: > On 04/26/2017 06:58 AM, Richard Biener wrote: >> >> On Tue, Apr 18, 2017 at 12:44 PM, Bin Cheng >> wrote: >>> >>> Hi, This patch handles more cheap cases in function >>> force_expr_to_var_cost, specifically, TRUNC_DIV_EXPR, BIT_AND_EXPR, >>> BIT_IOR_EXPR, RSHIFT_EXPR and BIT_NOT_EXPR. >>> >>> Is it OK? >> >> >> I wonder if using add_cost is good here. TRUNC_DIV by power of two better >> matches shift_cost, no, or div_pow2_cheap? Likewise for >> LSHIFT/RSHIFT. We do have [us]div_cost as well btw. And we have >> neg_cost. > > In an ideal world, we'd have a canoncial form and just handle hte canonical > form. But that hasn't ever really panned out for this kind of stuff in RTL > -- the decision about what is the preferred form of an expression changes > based on use context. > > I don't think these problems are as bad at the gimple level, but clearly > they still exist. > > The more we query the target, the less predictable the compiler's behavior > will be over time. It was a huge problem in RTL leading us to a point > where it became exceedingly difficult to predict how a change in a pass > would ultimately affect the performance across targets. Yeah, this is what I had in mind, but not expressed as clear as this. The patch's intention is to differentiate between expensive (div) and cheap operations. Thanks, bin > > That led to a guiding principle that we want to avoid querying the target in > gimple as much as possible. We've relaxed that somewhat (we have to be > pragmatic), but we need to be real careful here. > > So my recommendation would be to define a set of costs for gimple and get > those as solid as we can given an "ideal" target. Only query the target for > cases where it's critical. > > > Jeff