Re: [PATCH] alpha: add 128-bit shift helpers

[Matt Turner]

On Mon, Oct 12, 2026 at 8:37 AM David Laight
<david.laight.linux@xxxxxxxxx> wrote:
>
> On Fri,  9 Oct 2026 22:20:39 -0400
> Matt Turner <mattst88@xxxxxxxxx> wrote:
>
> > Selecting ARCH_SUPPORTS_INT128 lets generic code shift __int128 values by
> > a variable count. gcc open-codes such a shift when optimizing for speed,
> > but with CONFIG_CC_OPTIMIZE_FOR_SIZE=y it calls the libgcc routines
> > __ashlti3, __ashrti3 and __lshrti3 instead. The kernel does not link
> > against libgcc and Alpha does not provide them, so the link fails:
> >
> >   alpha-linux-ld: lib/ubsan.o: in function `get_signed_val':
> >   (.text+0x1c0): undefined reference to `__ashlti3'
> >   (.text+0x1f8): undefined reference to `__ashrti3'
> >   alpha-linux-ld: kernel/time/timekeeping.o: in function `delta_to_ns_safe':
> >   (.text+0x2ac): undefined reference to `__lshrti3'
> >
> > Provide the three helpers in C, as s390 does, and export them for
> > modules. They are built into the kernel proper rather than lib.a so the
> > exports are present even when nothing built in references them.
>
> Do they need an explicit (shift &= 63)?
> I've seen gcc/clang remove an explicit '&= 63' because they know the
> hardware instruction ignores the high bits.
> But I'm not sure what happens here.
> Adding it won't make much difference - unless it matters.

No, I don't think so, the 64-bit shift counts are already 0..63 for
any count in 0..127. The !shift check is what keeps 64 - shift from
reaching 64.

gcc doesn't remove an explicit mask here, by the way. It costs an
extra and per function on Alpha. Out-of-range counts give the same
results as libgcc's versions, which is all the callers could expect.