From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15337 invoked by alias); 14 Jan 2015 14:31:50 -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 15317 invoked by uid 89); 14 Jan 2015 14:31:49 -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_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f49.google.com Received: from mail-oi0-f49.google.com (HELO mail-oi0-f49.google.com) (209.85.218.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 14 Jan 2015 14:31:48 +0000 Received: by mail-oi0-f49.google.com with SMTP id a141so7499719oig.8 for ; Wed, 14 Jan 2015 06:31:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.134.237 with SMTP id pn13mr2658712oeb.82.1421245906548; Wed, 14 Jan 2015 06:31:46 -0800 (PST) Received: by 10.76.69.196 with HTTP; Wed, 14 Jan 2015 06:31:46 -0800 (PST) In-Reply-To: References: <877fwquwug.fsf@rasmusvillemoes.dk> Date: Wed, 14 Jan 2015 14:49:00 -0000 Message-ID: Subject: Re: RFC: Two minor optimization patterns From: Richard Biener To: GCC Patches Cc: Rasmus Villemoes Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg01067.txt.bz2 On Wed, Jan 14, 2015 at 3:26 PM, Marc Glisse wrote: > On Wed, 14 Jan 2015, Richard Biener wrote: > >> On Wed, Jan 14, 2015 at 1:45 PM, Marc Glisse wrote: >>> >>> On Tue, 13 Jan 2015, Rasmus Villemoes wrote: >>> >>>> diff --git gcc/match.pd gcc/match.pd >>>> index 81c4ee6..04a0bc4 100644 >>>> --- gcc/match.pd >>>> +++ gcc/match.pd >>>> @@ -262,6 +262,16 @@ along with GCC; see the file COPYING3. If not see >>>> (abs tree_expr_nonnegative_p@0) >>>> @0) >>>> >>>> +/* x + (x & 1) -> (x + 1) & ~1 */ >>>> +(simplify >>>> + (plus @0 (bit_and @0 integer_onep@1)) >>>> + (bit_and (plus @0 @1) (bit_not @1))) >>>> + >>>> +/* x | ~(x | y) -> x | ~y */ >>>> +(simplify >>>> + (bit_ior @0 (bit_not (bit_ior @0 @1))) >>>> + (bit_ior @0 (bit_not @1))) >>> >>> >>> >>> You may want to consider using has_single_use (see other patterns). >> >> >> Just to clarify, you mean on the (x | y) sub-expression? > > > I meant on (x & 1) for the first pattern and on ~(x | y) for the second one. > That is, cases where the transformation could actually increase the number > of statements (we don't have a convenient interface to check if (x+1) or ~y > are already available). > > (x | y) could sometimes be cheaper than y if it is already computed and it > shortens the lifetime of y, but we are way too early in the pipeline to make > an informed decision about that, so it seems better to canonicalize. Yeah. Note that I've not yet settled myself on how to attack the "single-use issue" generally. For example I'd like to do code generation for a specific simplification variant for value-numbering which can check the availability of expressions - here explicit has_single_use calls wil be prohibitive. It should be the responsibility of the caller to apply restrictions like this (but for the tree-ssa-forwprop.c case I've not yet come up with a reasonable way to tame things down...) Richard. > Now that I think about it, some platforms probably have an instruction > ornot, so my reasons above could be wrong... > -- > Marc Glisse