From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6694 invoked by alias); 8 May 2015 09:14:19 -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 6685 invoked by uid 89); 8 May 2015 09:14:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 08 May 2015 09:14:17 +0000 Received: by oign205 with SMTP id n205so53918423oig.2 for ; Fri, 08 May 2015 02:14:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.92.131 with SMTP id cm3mr2273923oeb.23.1431076454922; Fri, 08 May 2015 02:14:14 -0700 (PDT) Received: by 10.76.115.167 with HTTP; Fri, 8 May 2015 02:14:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 08 May 2015 09:14:00 -0000 Message-ID: Subject: Re: PR 64454: Improve VRP for % From: Richard Biener To: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00632.txt.bz2 On Mon, May 4, 2015 at 3:57 PM, Marc Glisse wrote: > 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? No, it's just nobody bothered to implement it. You also have to be careful as you can't replace reproducers of UNDEFINED but only uses that still result in UNDEFINED result (for example 0 * UNDEFINED is defined again). What I'd like to do at some point is have some common code that you can query what OP1 tree_code OP2 evaluates to if either op is UNDEFINED. For example UNDEF + X == UNDEF but UNDEF * X == 0 (as optimistical result, of course - the only not undefined case is for X == 0). UNDEF << X == 0 but UNDEF >> X == signed(x) ? UNDEF : 0. We have multiple passes that duplicate only parts of those "optimizations". Having a central place implementing this correctly would be nice. >> 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. Ok, I see. Richard. > -- > Marc Glisse