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

On Mon, Aug 17, 2026 at 7:16 PM Nick Desaulniers
<[email protected]> wrote:
>
> + John Paul
>
> On Mon, Aug 3, 2026 at 12:51 PM Nathan Chancellor <[email protected]> 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.

It builds a kernel that boots in qemu and on real hardware.

As of two days ago, it's capable of building itself and the 373
packages of a Gentoo stage3 + a few other things. These include glibc
and other core components (in a qemu-backend container on a fast
multicore amd64 system).

I would very much prefer to have the backend upstream, and I plan to
start a discussion on discourse.llvm.org this week. I think an
experimental backend is probably the limit of what makes sense for
Alpha?

If you have advice on going about this, I would welcome it (privately
or in reply to this thread).

Current diffstat is

461 files changed, 29735 insertions(+), 88 deletions(-)

of which {llvm,lld,clang}/test is

266 files changed, 9871 insertions(+), 4 deletions(-)

Currently reviewing and cleaning up, so the numbers will change.