Re: [PATCH 0/2] alpha: enable building with clang

[Nick Desaulniers]

+ John Paul

On Mon, Aug 3, 2026 at 12:51 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
>
> Hi Matt,
>
> On Mon, Aug 03, 2026 at 01:08:40PM -0400, Matt Turner wrote:
> > Two small patches to let the alpha kernel build with clang.
>
> Nice!
>
> > The first registers the clang target triple and stops passing -Wa,-mev6
> > when the compiler is not gcc.  That flag exists to keep gas from emulating
> > instructions it believes the target lacks; it is a gas-only option and
> > clang's integrated assembler does not emulate instructions, so it is not
> > needed there.
> >
> > The second fixes two uses of local register-asm variables that clang does
> > not honor.  clang treats `register unsigned long x __asm__("$N")` as the
> > named register only where the variable appears as an inline-asm operand,
> > so reading one to get the live $gp or $sp yields an undefined value.
> > trap_init() passed that to PAL_wrkgp and load_PCB() stored it into the
> > PCB for swpctx, either of which wedges an early boot.
> >
> > Note that the alpha backend is not in upstream LLVM.  It lives in
> >
> >   https://github.com/alphalinux-org/llvm-project
> >
> > and is a work in progress, so the scripts/Makefile.clang entry has no
> > effect with an upstream clang today.  I am sending this now because the
> > second patch is a real bug in its own right -- the register-asm reads are
> > only guaranteed to work by gcc's implementation, not by anything either
> > compiler documents -- but I understand if the kbuild side would rather
> > wait for the backend to land upstream.
>
> Yeah, I am not sure how I feel taking the target triple part of the
> first patch. On the one hand, I want it to be easy for you to test
> against upstream Linux but on the other, I do not want people to read
> this Makefile and assume that ARCH=alpha will work with an upstream
> clang.

Right. It's cool you have something building. I'm curious if the
resulting image boots? (That's the next major milestone).

I'm curious, since we've yet to have such a case of an out of tree
llvm backend, what's your plan, if any, to upstream your backend in
llvm-project proper? Perhaps as an experimental backend?  We have bugs
filed in our issue track for m68k which is experimental (but upstream)
in LLVM.

>
> We could add a comment that the backend is currently out of tree but
> that would go stale once it is actually upstream and it will be floating
> around for forever. Maybe a better compromise is taking arch/alpha
> changes now then landing the scripts/Makefile.clang change when you
> actually start upstreaming the backend, as being able to use an upstream
> version of clang should be relatively imminent at that point.
>
> --
> Cheers,
> Nathan



--
Thanks,
~Nick Desaulniers