From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80609 invoked by alias); 4 May 2015 13:57:38 -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 80598 invoked by uid 89); 4 May 2015 13:57:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 04 May 2015 13:57:37 +0000 Received: from eduroam-232a.sophia.inria.fr ([193.51.208.232]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2015 15:57:18 +0200 Date: Mon, 04 May 2015 13:57:00 -0000 From: Marc Glisse Reply-To: GCC Patches To: Richard Biener cc: GCC Patches Subject: Re: PR 64454: Improve VRP for % In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SW-Source: 2015-05/txt/msg00213.txt.bz2 On Mon, 4 May 2015, Richard Biener wrote: > On Sat, May 2, 2015 at 12:46 AM, Marc Glisse wrote: >> Hello, >> >> this patch tries to tighten a bit the range estimate for x%y. slp-perm-7.c >> started failing by vectorizing more than expected, I assumed it was a good >> thing and updated the test. I am less conservative than Jakub with division >> by 0, but I still don't really understand how empty ranges are supposed to >> be represented in VRP. >> >> Bootstrap+testsuite on x86_64-linux-gnu. > > Hmm, so I don't like how you (continute to) use trees for the constant > computations. wide-ints would be a better fit today. I also notice that > fold_unary_to_constant can return NULL_TREE and neither the old nor your > code handles that. You are right. I was lazy and tried to keep this part of the old code, I shouldn't have... > "empty" ranges are basically UNDEFINED. Cool, that's what I did. But I don't see code adding calls to __builtin_unreachable() when an empty range is detected. Maybe that almost never happens? > Aren't you pessimizing the case where the old code used > value_range_nonnegative_p() by just using TYPE_UNSIGNED? I don't think so. The old code only handled signed types in the positive case, while I have a more complete handling of signed types, which should do at least as good as the old one even in the positive case. -- Marc Glisse