On Thu, Nov 6, 2025 at 11:47 PM Jakub Jelinek <[email protected]> wrote:
>
> On Thu, Nov 06, 2025 at 10:49:01PM +0800, Kito Cheng wrote:
> > This patch implements _BitInt support for RISC-V target by defining the
> > type layout and ABI requirements.  The limb mode selection is based on
> > the bit width, using appropriate integer modes from QImode to TImode.
> > The implementation also adds the necessary libgcc version symbols for
> > _BitInt runtime support functions.
> >
> > gcc/ChangeLog:
> >
> >       PR target/117581
> >       * config/riscv/riscv.cc (riscv_bitint_type_info): New function.
> >       (TARGET_C_BITINT_TYPE_INFO): Define.
>
> > --- a/gcc/config/riscv/riscv.cc
> > +++ b/gcc/config/riscv/riscv.cc
> > @@ -14654,6 +14654,35 @@ riscv_c_mode_for_floating_type (enum tree_index ti)
> >    return default_mode_for_floating_type (ti);
> >  }
> >
> > +/* Implement TARGET_C_BITINT_TYPE_INFO.
> > +   Return true if _BitInt(N) is supported and fill its details into *INFO. 
> >  */
> > +bool
> > +riscv_bitint_type_info (int n, struct bitint_info *info)
> > +{
> > +  if (n <= 8)
> > +    info->limb_mode = QImode;
> > +  else if (n <= 16)
> > +    info->limb_mode = HImode;
> > +  else if (n <= 32)
> > +    info->limb_mode = SImode;
> > +  else if (n <= 64)
> > +    info->limb_mode = DImode;
> > +  else
> > +    {
> > +      if (TARGET_64BIT)
> > +     info->limb_mode = TImode;
> > +      else
> > +     info->limb_mode = DImode;
> > +    }
> > +
> > +  info->abi_limb_mode = info->limb_mode;
>
> I'm really surprised if this works at all, certainly it looks very
> problematic.  E.g. libgcc2.c __mulbitint* needs umul_ppmm in that case
> which will multiply 2 128-bit numbers and produce 256-bit one (split into
> two 128-bit numbers), similarly division etc.
> It is fine if your psABI (does it have _BitInt support?) says that the limbs
> should be 128-bit for 64-bit RISCV and 64-bit for 32-bit RISCV.

We defined that this year, so yeah :)

> So, the abi_limb_mode choice is reasonable.
> But unless the CPU is truly 128-bit and supports all basic arithmetics on
> 128-bit types in hw etc., the limb_mode choice looks bad.
> You really don't want the compiler emitted code to be handling 128-bit limbs
> at a time (or for 32-bit target 64-bit limbs at a time), it is much better
> to handle 64-bit limbs at a time or 32-bit limbs for 32-bit target.
> Not to mention libgcc.
> So, for info->limb_mode I think you want instead something like
> aarch64 does, which is:
> ...

Thanks for the suggestion, and I think I should doing that after I
reading more comment in the code :P

>
> > +  info->big_endian = TARGET_BIG_ENDIAN;
> > +  info->extended = true;
>
> Though, because you've chosen info->extended (is it what
> RISCV psABI requires), there is further complication.
> I'm afraid the generic code right now will not take care of doing an
> extension into the most significant 64 (or for !TARGET_64BIT 32)
> bits of _BitInts like _BitInt(1025).  LoongArch chose to use info->extended
> but its psABI says that it only extends the last half-limb, and s390x as
> another arch with info->extended has abi_limb_mode == limb_mode always
> (uses 64-bit limbs rather than 128-bit limbs in the psABI).
>
> BTW, when you choose info->extended, you should edit
> gcc/testsuite/gcc.dg/bitintext.h
> and add the extension support in there.

Thanks for pointing this out :)

>
>         Jakub
>

Reply via email to