From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126370 invoked by alias); 30 May 2017 15:35:55 -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 126342 invoked by uid 89); 30 May 2017 15:35:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:sk:mail-wr, H*RU:sk:mail-wr, H*r:sk:mail-wr, H*i:sk:4MWA5b3 X-HELO: mail-wr0-f178.google.com Received: from mail-wr0-f178.google.com (HELO mail-wr0-f178.google.com) (209.85.128.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 May 2017 15:35:53 +0000 Received: by mail-wr0-f178.google.com with SMTP id g76so2957395wrd.1 for ; Tue, 30 May 2017 08:35:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=PVxJq9MHosKFzJCiRXMx8NQhCVU1x5B/TPzAszJb7Es=; b=XbjpymRON2FmEW3kDGhcEDGaqE3aXN/QJLbsmt0i16nDd/FGw3ICTkM9Y0m4ZeqGzc Tn7cZH9DdDr7jNHjKnGNkJ8at12zpuYI+kfW7WXBn2Ctxqbtkd6pj34Ug9X1WoRB0GEk +cY0i0uIFpMYLLSRbG3tPDfYPIKbAtXWKFRUxSJvT6bQPR0yDfDC6TP0FHGvi/C6+uxN VwCj1+owod+AITGEj1STYAkonT91YsVXiLfGFDptQ/RKL1ZZtbzZ+thpvCXc2OFhAgMN 8VC43DO1CSi++dYXqVJqgyhqD92Ke9YVJUMSsTFWWrMajimv0/dFK1BnCHZqS9Y3D/Rx ogig== X-Gm-Message-State: AODbwcDAA+VSt8aFroDVTrjuQ/8Gmjf8BvuPDeEME2H/M6XGEuVyMR4U l90h8VX05LFooEsE X-Received: by 10.223.132.163 with SMTP id 32mr14844719wrg.154.1496158554898; Tue, 30 May 2017 08:35:54 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id 201sm19441438wmh.22.2017.05.30.08.35.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 May 2017 08:35:53 -0700 (PDT) From: Richard Sandiford To: Yuri Gribov Mail-Followup-To: Yuri Gribov ,GCC Patches , Alan Modra , rguenth@gcc.gnu.org, richard.sandiford@linaro.org Cc: GCC Patches , Alan Modra , rguenth@gcc.gnu.org Subject: Re: [PATCH 3/4 v3][PR 67328] Added bool conversion for wide_ints References: <87tw42onqo.fsf@linaro.org> <87lgpeocnf.fsf@linaro.org> Date: Tue, 30 May 2017 15:47:00 -0000 In-Reply-To: (Yuri Gribov's message of "Tue, 30 May 2017 13:31:57 +0100") Message-ID: <87h902nyqv.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-05/txt/msg02280.txt.bz2 Yuri Gribov writes: > On Tue, May 30, 2017 at 11:35 AM, Richard Sandiford > wrote: >> Yuri Gribov writes: >>> On Tue, May 30, 2017 at 7:35 AM, Richard Sandiford >>> wrote: >>>> Yuri Gribov writes: >>>>> From 330209f721a598ec393dcb5d62de3457ee282153 Mon Sep 17 00:00:00 2001 >>>>> From: Yury Gribov >>>>> Date: Fri, 26 May 2017 07:53:10 +0100 >>>>> Subject: [PATCH 3/4] Added bool conversion for wide_ints. >>>>> >>>>> gcc/ >>>>> 2017-05-26 Yury Gribov >>>>> >>>>> * wide-int.cc (wi::zero_p_large): New method. >>>>> * wide-int.h (wi::zero_p): New method. >>>> >>>> Do you still need this bit? It looks like it isn't used by the other >>>> parts of the series. >>>> >>>> The idea was that wi::eq_p (x, 0) (or just x == 0, if x is a >>>> wide-int-based type) is supposed to be as fast as a dedicated zero check. >>>> It'd be OK to have a helper function anyway, but it should probably be >>>> defined using wi::eq_p. >>>> >>>> The zero_p_large fallback can never return true, since a zero of >>>> any precision will have a length of 1. >>> >>> Thanks Richard, I'll update the patch. The bool check is used in >>> successive patch (4/4), in >>> widest_int mask = wi::to_widest (@2); >>> bool mask_all_ones_p = !(mask & (mask + 1)); >> >> Ah, OK. That's equivalent to mask == -1 (or wi::eq_p (@2, -1), to avoid >> the temporary). > > Hm, is it? Current check ensures that N consecutive LSBs are set, not > that all bits are set. Perhaps variable name should be changed to > reflect this better. Sorry, yeah, was going off the variable name rather than what the test actually did... >> I think it'd be better to use one of those instead. >> There's an argument that if ! is defined, it should return an integer >> of the same precision as the argument. > > True. Perhaps I should make separate > wide_int operator !() > and > bool operator bool() Why not just a comparison? It seems clearer IMO. Thanks, Richard