From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100243 invoked by alias); 20 Nov 2017 14:59:37 -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 100233 invoked by uid 89); 20 Nov 2017 14:59:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Nov 2017 14:59:36 +0000 Received: by mail-wm0-f42.google.com with SMTP id 128so10812906wmo.3 for ; Mon, 20 Nov 2017 06:59:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a61BVUnwvPXvR3QKcMOu+odrlx2lpDEo6nb9QSSgVSQ=; b=FcJTtXsSVWwNhuOFaMK1+6bhfBFoTwPxjq+kHzQ1ypi8kBC5ztYsWj6KxLfA01dDun xL8t7JBNfa/k6Z6m6akarNiXFIzpYeNxbMSbpQrD5mEwQCrY9XcxY3xvFNSjMlC1wq79 5TRMOKoOHoKXONzSedffO/gv7hnhtOO9l2oNyAuxizxvMFEcrvm76I9VYvttbgF14MBs c7QMZoBxr2YNzRqWYCuWtO0AoGWAlENIjbYPG6CrISmMlsDqvDqSVe82zd287iz/+vk4 qINVsi7J5q50UgggBKgMlMdjzTOiUe1oYakQVOq5D+lRXgmupbvpOaGh+YxJZi6lUIyO Nc4g== X-Gm-Message-State: AJaThX4oHKExSy2JqZiwCoqagmRY3IoGSRY9zmzHUyNxWUL0Fbo6Psky 1f17FT0vOh7tDcdbA44q5IPH+IInJQXj/FhRh4o= X-Google-Smtp-Source: AGs4zMbGYHNfj9Kbi60Sjxi/qkCK3EsuhEdZz/vB9G84JzewM+nmi1PM4S5lIWasl4w/Rq4xM942E8qKHtkuQGajD+0= X-Received: by 10.80.208.195 with SMTP id g3mr19850039edf.246.1511189974243; Mon, 20 Nov 2017 06:59:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Mon, 20 Nov 2017 06:59:33 -0800 (PST) In-Reply-To: References: From: Richard Biener Date: Mon, 20 Nov 2017 15:09:00 -0000 Message-ID: Subject: Re: VRP: x+1 and -x cannot be INT_MIN To: Marc Glisse Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01777.txt.bz2 On Mon, Nov 20, 2017 at 3:10 PM, Marc Glisse wrote: > On Mon, 20 Nov 2017, Richard Biener wrote: > >>> I had to adapt one testcase where for VR_VARYING | [1, 1] we used to >>> produce >>> ~[0, 0] and now produce [-INT_MAX, INT_MAX]. I am surprised at how late >>> the >>> transformation now happens (only after removing __builtin_unreachable, in >>> forwprop3, while trunk currently has it in evrp IIRC), but I didn't >>> investigate, doesn't seem like the right time with all the VRP changes >>> going >>> on. >> >> >> Interesting - can you open a bugreport so we don't forget? I suspect it's >> the effect of zero_nonzero_bits_from_vr handling VARYING and [INT_MIN, >> INT_MAX] >> differently rippling down. At some point in time I wanted to get rid of >> VARYING >> in favor of [INT_MIN, INT_MAX] ... > > > I filed PR 83072 about missing the optimization in evrp, but now I am not > sure if that's what you wanted in the PR or if you wanted one about chosing > between ~[0, 0] and [-INT_MAX, INT_MAX] for VR_VARYING | [1, 1]... Yes, the one choosing between these two. The EVRP missed optimization is of course also useful to track. Richard. > -- > Marc Glisse