From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-484563-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 90212 invoked by alias); 28 Aug 2018 09:27:19 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 90202 invoked by uid 89); 28 Aug 2018 09:27:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mail-lj1-f172.google.com
Received: from mail-lj1-f172.google.com (HELO mail-lj1-f172.google.com) (209.85.208.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Aug 2018 09:27:18 +0000
Received: by mail-lj1-f172.google.com with SMTP id v26-v6so818814ljj.3        for <gcc-patches@gcc.gnu.org>; Tue, 28 Aug 2018 02:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:references:in-reply-to:from:date:message-id:subject:to         :cc;        bh=wz8J76IJU2Emij+TlKo+cISWesmKMQymCRKraThcSoM=;        b=iCR+s2sjJmYuDvKf2Oc9prfXdYhalsVFOovx/PHOsKQE4vi5f7aw4tlCu0MrIGCcJ5         z0Dkqug92Ok6bvuxpzeDP5GFjM312FCB6o2AaGtvmQVN1qWqLmt3vPeKbkpYLybbt0sg         E0YqtvemM40P70hrWij7hzVogjOPbm4syxvlFC9z0uioUFlsI6A72GgXwCqDV301YPWP         iLtaYgaYi87SPCi0Lqc7k6CWEGXlYlWcLWP+IizDDBlBH6A1U6/d1oYSUEW5yMu0lAdR         WKw0Fy+p5an+a5QcIDBu3lcdONEuoPltfBRoJMN4uJ+SkCT716BphvdVJxrbjeH/ivMA         8Czw==
MIME-Version: 1.0
References: <ca140cb9-b884-6ff2-3a6e-494fb22cee22@redhat.com>
In-Reply-To: <ca140cb9-b884-6ff2-3a6e-494fb22cee22@redhat.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Tue, 28 Aug 2018 09:27:00 -0000
Message-ID: <CAFiYyc1nE8qiD6E__LyRRFYwdjmvrs4vGWU9k-dJC+0rgNtQpg@mail.gmail.com>
Subject: Re: VRP: abstract out wide int CONVERT_EXPR_P code
To: Aldy Hernandez <aldyh@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2018-08/txt/msg01736.txt.bz2

On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>
> Howdy!
>
> Phew, I think this is the last abstraction.  This handles the unary
> CONVERT_EXPR_P code.
>
> It's the usual story-- normalize the symbolics to [-MIN,+MAX] and handle
> everything generically.
>
> Normalizing the symbolics brought about some nice surprises.  We now
> handle a few things we were punting on before, which I've documented in
> the patch, but can remove if so desired.  I wrote them mainly for myself:
>
> /* NOTES: Previously we were returning VARYING for all symbolics, but
>     we can do better by treating them as [-MIN, +MAX].  For
>     example, converting [SYM, SYM] from INT to LONG UNSIGNED,
>     we can return: ~[0x8000000, 0xffffffff7fffffff].
>
>     We were also failing to convert ~[0,0] from char* to unsigned,
>     instead choosing to return VR_VARYING.  Now we return ~[0,0].  */
>
> Tested on x86-64 by the usual bootstrap and regtest gymnastics,
> including --enable-languages=all, because my past sins are still
> haunting me.
>
> OK?

The new wide_int_range_convert_tree looks odd given it returns
tree's.  I'd have expected an API that does the conversion resulting
in a wide_int range and the VRP code adapting to that by converting
the result to trees.

Richard.