From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96037 invoked by alias); 28 Aug 2018 09:31:29 -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 94961 invoked by uid 89); 28 Aug 2018 09:31:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy= X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Aug 2018 09:30:42 +0000 Received: by mail-wm0-f49.google.com with SMTP id q8-v6so1244799wmq.4 for ; Tue, 28 Aug 2018 02:30:28 -0700 (PDT) Return-Path: Received: from abulafia.quesejoda.com (131.107.133.37.dynamic.jazztel.es. [37.133.107.131]) by smtp.gmail.com with ESMTPSA id j44-v6sm1397916wre.40.2018.08.28.02.30.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 02:30:25 -0700 (PDT) Subject: Re: VRP: abstract out wide int CONVERT_EXPR_P code To: Richard Biener Cc: GCC Patches References: From: Aldy Hernandez Message-ID: <7588d9ab-348a-6360-c79c-e6afcc85c3a3@redhat.com> Date: Tue, 28 Aug 2018 09:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg01737.txt.bz2 On 08/28/2018 05:27 AM, Richard Biener wrote: > On Mon, Aug 27, 2018 at 2:24 PM Aldy Hernandez 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. Hmmm, yeah. I agree. I'll think about this some more and see what I can come up with. Thanks. Aldy