From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24935 invoked by alias); 27 May 2014 10:12:43 -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 24922 invoked by uid 89); 27 May 2014 10:12:42 -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-wg0-f43.google.com Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 27 May 2014 10:12:41 +0000 Received: by mail-wg0-f43.google.com with SMTP id l18so9243571wgh.14 for ; Tue, 27 May 2014 03:12:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.183.131 with SMTP id em3mr36069116wic.56.1401185558011; Tue, 27 May 2014 03:12:38 -0700 (PDT) Received: by 10.194.119.193 with HTTP; Tue, 27 May 2014 03:12:37 -0700 (PDT) In-Reply-To: <2973073.WOSPpEhgk4@polaris> References: <1466969.VvFMuDKXoD@polaris> <53896104.oWY7sHq2zD@polaris> <2973073.WOSPpEhgk4@polaris> Date: Tue, 27 May 2014 10:12: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-05/txt/msg02260.txt.bz2 On Tue, May 27, 2014 at 11:59 AM, Eric Botcazou wrote: >> I'm asking to merge them (move them to fold_comparison). > > OK, I'll repost a first patch doing only the fold-const.c massaging. > >> Yeah, it would be nice to see some support. The most interesting cases >> will be symbolic-singleton +- CST where the offset shrinks a constant offset >> in a symbolic A +- CST (thus we don't get into any overflow issues). Thus >> handling >> >> [a + 1, a + 1] - [1, 1] -> [a, a] >> >> for example. We get the offsetted singleton symbolic ranges from >> conditional asserts a lot. > > For the case at hand, you have [x + 1, INF] for y and you want to evaluate the > range of y - x, so you really don't want to use the range of x... Ok. That's similar to the issue I try to address with the VRP snipped I posted yesterday. 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. Richard. > -- > Eric Botcazou