From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 034023858428 for ; Mon, 17 Apr 2023 18:48:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 034023858428 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102b.google.com with SMTP id hg12so12227165pjb.2 for ; Mon, 17 Apr 2023 11:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681757290; x=1684349290; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ht8QTxs3MyQ/56OI+fPOLt7+ZZ0VZx5tpD+Njkx1w9Y=; b=s2wW4D8h0peO3DLOFfOYq7WQbRHCoKXw6J1yZqBGtAfNuwYqlIsX8SUW/iv7NFUzAH lNAoFjojqVhf+CWbeGJie/S4FxyPnDY+i+663YwV9QmY4EqoQ7/Rb+OToA3KqOAyh+N/ noZdHhqRXFx8VtW5ZcIRGOUFf0Myltb+Hrk4VCAHhX2UscLIhx+iQuPn1bapSgtBJ5hp b95k/imw9vry3xxo1K2cABmjw7vVf4dcyqFs0hOjcr/kXZppu+LThPBRu3QMJm1lD1gY S3/3X1XCGQV1G3my1eSVsaLD1OIjGmXFwZx87wWLUs7/faijmGqfKuNB/lE76ogL8dYF 46pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681757290; x=1684349290; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ht8QTxs3MyQ/56OI+fPOLt7+ZZ0VZx5tpD+Njkx1w9Y=; b=ldnjKFNQ0qeSgfSwoPL8fC0MCKhOQZ9lfiAerig96QRJfqkLhdM6I+EJrjcCJO2grb zrUucOFNHnsJ840MsbMu+E0sS8q5Wx7+ftUGRYpLfJYSmSwhkrP0/khZkGSYT3QPXBVG ukC1+cd9cIqUqRYPqWh6gpaGB1L5tmpYkMahwSwHh7dQPzbKhJKIYWo1UKgXY6zvCZqD f2tZXOaC2B73+XSvpMOgRv4m+ZNt1rTvd4dbjRSXTF+fbdjylrRuR13g8Z2hn9F2Qtoh eOM/3ID0Q3cb65vsJP2UFaALD8MFtNLWR/l8Cikw4jiU6clpfLwfVT7eEw+JpZ3+Z+sU X2Wg== X-Gm-Message-State: AAQBX9f7GdqM8JkklJ5XNb7zw7QTlbmA44yAiKZVix/gNnLNvcWrcOub iGv2BWUi0LGKAlI04Q10mnla2DTR+zTCjkjty4c= X-Google-Smtp-Source: AKy350bT5hkNMHmZT2j9RG2ZRuKJXTl+nT//HKM65Nlm91xNLjIKg5bmV4yUuctzkyk2UMpXmg8tUZDozy1BKucizNM= X-Received: by 2002:a17:90b:1296:b0:248:8399:1f7c with SMTP id fw22-20020a17090b129600b0024883991f7cmr106574pjb.38.1681757289713; Mon, 17 Apr 2023 11:48:09 -0700 (PDT) MIME-Version: 1.0 References: <20230417183917.216257-1-aldyh@redhat.com> In-Reply-To: <20230417183917.216257-1-aldyh@redhat.com> From: Andrew Pinski Date: Mon, 17 Apr 2023 11:47:58 -0700 Message-ID: Subject: Re: [PATCH] Abstract out calculation of max HWIs per wide int. To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Apr 17, 2023 at 11:44=E2=80=AFAM Aldy Hernandez via Gcc-patches wrote: > > I'm about to add one more use of the same snippet of code, for a total > of 4 identical calculations in the code base. > > This seems safe enough even before the release, since this file hardly > changes and I'm pretty much the only one who's touched it this year. > > OK for trunk? > > gcc/ChangeLog: > > * wide-int.h (WIDE_INT_MAX_HWIS): New. > (class fixed_wide_int_storage): Use it. > (trailing_wide_ints ::set_precision): Use it. > (trailing_wide_ints ::extra_size): Use it. > --- > gcc/wide-int.h | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/gcc/wide-int.h b/gcc/wide-int.h > index a450a744c9f..6be343c0eb5 100644 > --- a/gcc/wide-int.h > +++ b/gcc/wide-int.h > @@ -264,6 +264,10 @@ along with GCC; see the file COPYING3. If not see > /* The number of HWIs needed to store an offset_int. */ > #define OFFSET_INT_ELTS (ADDR_MAX_PRECISION / HOST_BITS_PER_WIDE_INT) > > +/* The max number of HWIs needed to store a wide_int of PRECISION. */ > +#define WIDE_INT_MAX_HWIS(PRECISION) \ > + ((PRECISION + HOST_BITS_PER_WIDE_INT - 1) / HOST_BITS_PER_WIDE_INT) Does it make sense to use an constexpr inline function instead of a define here since GCC is written in C++11 after all? That is: constexpr inline unsigned WIDE_INT_MAX_HWIS(unsigned precision) { return ((precision + HOST_BITS_PER_WIDE_INT - 1) / HOST_BITS_PER_WIDE_INT= ); } Thanks, Andrew Pinski > + > /* The type of result produced by a binary operation on types T1 and T2. > Defined purely for brevity. */ > #define WI_BINARY_RESULT(T1, T2) \ > @@ -1214,7 +1218,7 @@ template > class GTY(()) fixed_wide_int_storage > { > private: > - HOST_WIDE_INT val[(N + HOST_BITS_PER_WIDE_INT + 1) / HOST_BITS_PER_WID= E_INT]; > + HOST_WIDE_INT val[WIDE_INT_MAX_HWIS (N)]; > unsigned int len; > > public: > @@ -1475,8 +1479,7 @@ trailing_wide_ints ::set_precision (unsigned int= precision, > gcc_checking_assert (num_elements <=3D N); > m_num_elements =3D num_elements; > m_precision =3D precision; > - m_max_len =3D ((precision + HOST_BITS_PER_WIDE_INT - 1) > - / HOST_BITS_PER_WIDE_INT); > + m_max_len =3D WIDE_INT_MAX_HWIS (precision); > } > > /* Return a reference to element INDEX. */ > @@ -1505,8 +1508,7 @@ inline size_t > trailing_wide_ints ::extra_size (unsigned int precision, > unsigned int num_elements) > { > - unsigned int max_len =3D ((precision + HOST_BITS_PER_WIDE_INT - 1) > - / HOST_BITS_PER_WIDE_INT); > + unsigned int max_len =3D WIDE_INT_MAX_HWIS (precision); > gcc_checking_assert (num_elements <=3D N); > return (num_elements * max_len - 1) * sizeof (HOST_WIDE_INT); > } > -- > 2.39.2 >