From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3946 invoked by alias); 2 Jun 2014 10:37:51 -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 3935 invoked by uid 89); 2 Jun 2014 10:37:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f169.google.com Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Jun 2014 10:37:49 +0000 Received: by mail-wi0-f169.google.com with SMTP id hi2so4058710wib.2 for ; Mon, 02 Jun 2014 03:37:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.45 with SMTP id mz13mr20915994wic.32.1401705466667; Mon, 02 Jun 2014 03:37:46 -0700 (PDT) Received: by 10.194.219.97 with HTTP; Mon, 2 Jun 2014 03:37:46 -0700 (PDT) In-Reply-To: References: <1466969.VvFMuDKXoD@polaris> <2973073.WOSPpEhgk4@polaris> <2272943.QullF6hSsT@polaris> Date: Mon, 02 Jun 2014 10:37:00 -0000 Message-ID: Subject: Re: [RFC] optimize x - y cmp 0 with undefined overflow From: Richard Biener To: Eric Botcazou Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00057.txt.bz2 On Mon, Jun 2, 2014 at 12:36 PM, Richard Biener wrote: > On Fri, May 30, 2014 at 10:48 AM, Eric Botcazou wrote: >>> I'd say we still handle "basic" symbolic range ops in >>> extract_range_from_binary_1 >>> but in extract_range_from_binary_expr for a symbolic op0 we try to simplify >>> it with both [op1, op1] and with the value-range of op1 until we get a >>> non-varying range as result. Not sure if it's worth restricting that >>> to the case >>> where op0s value-range refers to op1 or vice versa, and eventually only >>> use op1 symbolically then. >> >> Patch along these lines attached. A bit heavy as expected, but it's VRP... >> It deals with my pet problem, you might want to check it does so with yours. >> >> Tested on x86_64-suse-linux with no regressions. > > Looks mostly ok. Any reason why you are not re-creating > MINUS_EXPR in build_symbolic_expr? That is, build > inv - t (for non-pointers, of course)? Otherwise if a range > becomes -t + inv that will no longer match get_single_symbol > for further propagation? > > Then I'm not sure if > > + /* Try with VR0 and [-INF, OP1]. */ > + set_value_range (&new_vr1, VR_RANGE, vrp_val_min (expr_type), op1, NULL); > + extract_range_from_binary_expr_1 (vr, code, expr_type, &vr0, &new_vr1); > + if (vr->type != VR_VARYING) > + return; > + > + /* Try with VR0 and [OP1, +INF]. */ > + set_value_range (&new_vr1, VR_RANGE, op1, vrp_val_max (expr_type), NULL); > + extract_range_from_binary_expr_1 (vr, code, expr_type, &vr0, &new_vr1); > + if (vr->type != VR_VARYING) > + return; > > is a safe thing to do. If it does make a difference to try [-INF, OP1], > [OP1, +INF] instead of just [OP1, OP1] then at least it's very suspicious ;) > (or an "easy" missed optimization). > > So - can you fix the negate thing and drop the four cases trying > the +-INF based ranges? Btw, the testcases are missing in the patch so I can't have a look myself. Richard. > Thanks, > Richard. > >> >> 2014-05-30 Eric Botcazou >> >> * tree-vrp.c (get_single_symbol): New function. >> (build_symbolic_expr): Likewise. >> (symbolic_range_based_on_p): New predicate. >> (extract_range_from_binary_expr_1): Deal with single-symbolic ranges >> for PLUS and MINUS. Do not drop symbolic ranges at the end. >> (extract_range_from_binary_expr): Try harder for PLUS and MINUS if >> operand is symbolic and based on the other operand. >> >> >> 2014-05-30 Eric Botcazou >> >> * gcc.dg/tree-ssa/vrp93.c: New test. >> * gnat.dg/opt38.adb: Likewise. >> >> >> -- >> Eric Botcazou