HI Jeff:

Yeah, I agreed, I sent out v3 for addressing all failures from CI, and
I guess I need some explicit approval for the [2/2] VN part.

On Mon, Jan 12, 2026 at 10:25 PM Jeffrey Law
<[email protected]> wrote:
>
>
>
> On 1/9/2026 3:08 PM, Jakub Jelinek wrote:
> > On Thu, Jan 08, 2026 at 08:50:35AM -0700, Jeffrey Law wrote:
> >>> +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 (n <= 128 && TARGET_64BIT)
> >>> +    info->limb_mode = TImode;
> >>> +  else
> >>> +    info->limb_mode = TARGET_64BIT ? DImode : SImode;
> >> So I've never looked at how BitInt works, so if this is totally off-base
> >> just say so ;-)
> >>
> >> It seems a bit odd to have the limb_mode by DImode for rv32 when we don't
> >> have any DImode operations in rv32.  Though we allow TImode for rv64, so
> >> perhaps we're just relying on widening capabilities in the expander
> >> interfaces under the hood?
> >>
> >> It also seems a bit odd that for n > 128 and TARGET_64BIT that we select
> >> DImode when we use TImode for sizes > 64, but <= 128.   Similarly for
> >> !TARGET_64BIT we have SImode and DImode respectively.
> > It depends on what the psABI says (if it says anything at all).
> > What Kito posted is quite usual thing (except for the abi_limb_mode !=
> > limb_mode && extended = true case which still needs to have a few spots
> > in the generic handling tweaked (like for arm32).
> Thanks for the clarification.   It just looked odd, my comments weren't
> based on knowing anything at all about how this stuff works.
>
> Kito -- I think this should go forward ASAP to get as much soak time as
> possible.
>
> jeff
>
>

Reply via email to