[PATCH] Abstract out calculation of max HWIs per wide int.

[Richard Biener]

On Mon, Apr 17, 2023 at 8:50 PM Aldy Hernandez via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> On 4/17/23 20:47, Andrew Pinski wrote:
> > On Mon, Apr 17, 2023 at 11:44 AM Aldy Hernandez via Gcc-patches
> > <gcc-patches@gcc.gnu.org> 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 <N>::set_precision): Use it.
> >>          (trailing_wide_ints <N>::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);
> > }

Hmm, but does that force inlining?  Not all touched contexts require a constant?

I'd be curious what C++ experts say here.

> I am following the current style in wide-int.h, both in naming as well
> as macros, but I have no strong opinions.

I'm OK with macros since as you say it follows existing style.

OK for trunk (but not the branch).

Richard.

> I'm happy to do whatever y'all agree is best.
> Aldy
>