From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31226 invoked by alias); 6 Jun 2014 10:54:08 -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 31217 invoked by uid 89); 6 Jun 2014 10:54:08 -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 autolearn=ham version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 Jun 2014 10:54:06 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 6F88627EF526; Fri, 6 Jun 2014 12:54:03 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elLf0CeSg_gd; Fri, 6 Jun 2014 12:54:03 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 4F76627EF521; Fri, 6 Jun 2014 12:54:03 +0200 (CEST) From: Eric Botcazou To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [RFC] optimize x - y cmp 0 with undefined overflow Date: Fri, 06 Jun 2014 10:54:00 -0000 Message-ID: <2380818.KtDek0hH5m@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.29-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: References: <1466969.VvFMuDKXoD@polaris> <1624774.xzcp69eE4l@polaris> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2014-06/txt/msg00598.txt.bz2 > So when computing a range for z in > > z = y - x; > > with x = [-INF, y - 1] and y = [x + 1, +INF] (deduced from !(x >= y)) we > fail to do sth sensible with [y, y] - [-INF, y - 1] or [x + 1, +INF] - [x, > x] but we do sth with [x + 1, +INF] - [-INF, x]? That seems odd to me. > > With the patch we compute z to [1, +INF(OVF)] Right, and note the overflow. > Going the [x + 1, +INF] - [x,x] path first we obtain > > [1, -x + INF] > > which fails the sanity checking > > cmp = compare_values (min, max); > if (cmp == -2 || cmp == 1) > { > /* If the new range has its limits swapped around (MIN > MAX), > then the operation caused one of them to wrap around, mark > the new range VARYING. */ > set_value_range_to_varying (vr); > } > else > set_value_range (vr, type, min, max, NULL); > > but clearly the same reasoning you can apply that makes trying > with [-INF, x] valid (it's just enlarging the range) can be applied > here, too, when computing +INF - x for the upper bound. We can > safely increase that to +INF making the range valid for the above > test. I don't think we can enlarge to +INF because -x + INF can overflow, we can only enlarge to +INF(OVF). > But I wonder what code path in the routine still relies on that sanity > checking to produce a valid result (so I'd rather try removing it, or > taking uncomparable bounds as a valid range). > > Simplest would be to simply do > > set_value_range (vr, type, min, max, NULL); > return; > > and be done with that in the plus/minus handling. With that the > testcase optimizes ok for me. With [1, -x + INF] as the resulting range? But it can be bogus if x is itself equal to +INF (unlike the input range [x + 1, +INF] which is always correct) so this doesn't look valid to me. I don't see how we can get away without a +INF(OVF) here, but I can compute it in extract_range_from_binary_expr_1 if you prefer and try only [op0,op0] and [op1,op1]. -- Eric Botcazou