From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25786 invoked by alias); 6 Jun 2014 15:45:28 -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 25756 invoked by uid 89); 6 Jun 2014 15:45:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 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-f177.google.com Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 06 Jun 2014 15:45:22 +0000 Received: by mail-wi0-f177.google.com with SMTP id f8so1239326wiw.16 for ; Fri, 06 Jun 2014 08:45:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.225 with SMTP id l1mr8263978wjq.25.1402069519958; Fri, 06 Jun 2014 08:45:19 -0700 (PDT) Received: by 10.194.219.97 with HTTP; Fri, 6 Jun 2014 08:45:19 -0700 (PDT) In-Reply-To: <2380818.KtDek0hH5m@polaris> References: <1466969.VvFMuDKXoD@polaris> <1624774.xzcp69eE4l@polaris> <2380818.KtDek0hH5m@polaris> Date: Fri, 06 Jun 2014 15:45: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/msg00625.txt.bz2 On Fri, Jun 6, 2014 at 12:52 PM, Eric Botcazou wrote: >> 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) Hmm, indeed. > 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]. Yeah, I'd prefer that. Thanks, Richard. > -- > Eric Botcazou