Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain

[Ard Biesheuvel]

On Mon, 13 Apr 2020 at 22:45, Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote:
>
> On Fri, Apr 10, 2020 at 6:09 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >
> > On Fri, 10 Apr 2020 at 14:33, Russell King - ARM Linux admin
> > <linux@xxxxxxxxxxxxxxx> wrote:
...
> > > If your compiler/assembler only implements what is in the latest ARM
> > > ARM, then it is not going to be suitable for these older CPUs and
> > > alternate vendor "ARM compatible" CPUs.
> > >
> >
> > Indeed, and I'm a bit disappointed at the willingness to leave stuff
> > by the wayside, especially since Clang's integrated assembler has no
> > other benefit to it than being built into the compiler.
>
> I don't disagree.  I also wish LLVM had a backend for every
> architecture that GCC does.  But resources are finite and there are
> more fires than firemen.  It gets really hard to justify a high
> priority for certain things over others.  Doubly-so for hardware no
> longer in production.  Triply-so when the ISA vendor doesn't provide
> information in available reference manuals.  I'm happy to push for
> more investment in LLVM to support the Linux kernel from Google
> internally; maybe you can help do so from ARM?  That was my appeal to
> ARM back in February; support for newest ISA extensions is great,
> support for existing instructions is great, too.  (And not having to
> choose between one or the other is preferrable, given the amount of
> resources available).
>

Sure. But my point was really that disabling stuff left and right just
so we can get to the finish line is fine for internal kernel-on-clang
development, but I'd expect the contributions upstream to be a bit
more considerate of other concerns, such as not regressing in terms of
functionality.

> My thoughts on the benefits of this approach to using Clang's
> integrated assembler:
> 1. continuous integration and randconfigs.  We need CI to help us spot
> where things are still broken, and help us from regressing the ground
> we've fought for.  We can't expect kernel developers to test with
> LLVM.  Currently, we have LLVM builds in numerous kernel continuous
> integration services (KernelCI, Kbuild test robot "0day bot", Linaro's
> TCWG, Syzcaller, and our own CI).  For services that are bisecting and
> notifying authors, they are currently harassing authors for
> pre-existing conditions that the service uncovered via randconfig.
> This is very very dangerous territory to be in.  If authors start
> ignoring build reports due to false positives or false negatives, it
> becomes a weak signal that tends to be ignored.  Then when real bugs
> are uncovered, the actual bugs get ignored.  We don't want that.  If a
> canary dies in a coal mine, but no one notices, was it for naught?
>

OK, so you are saying you need the Clang *assembler* to perform CI on
C pieces that we can now build with the Clang compiler, and we don't
want to regress on that? Is this because the cross-assemblers are
missing from the CI build hosts?

> 2. It helps us quantify how broken we are, via `grep` and `wc`.  LLVM
> is in no way a perfect substitute for GNU utilities, but it's not too
> far off either.  As an imperfect substitute, there's a lot of work
> both on the toolchain side and sources of various codebases in terms
> of toolchain portability.  Being able to quantify what doesn't work
> let's us be clear in which ways LLVM is not a perfect substitute, but
> also where and how much resources we need to get closer.  That helps
> then with planning and prioritization.  The proper thing to do is to
> bury the dead but at this point we only have resources to collect dog
> tags and keep moving.  That doesn't rule out revisiting implementing
> iWMMXT in the future.
>

To be honest with you, I don't actually think iwmmxt is that
important. But I have already demonstrated how we can use a couple of
macros to emit the same instructions without resorting to bare
opcodes, so there is really no need to disable pieces left and right
because the Clang assembler does not support them outright - it just
needs someone to care enough about this, rather than rush through the
list with a tick the box attitude, and rip out the pieces that look a
bit too complicated.

> 3. Testing Clang's assembler allows for us to do kernel builds without
> binutils.  This work is helping uncover places within the kernel where
> the build is not hermetic.  We're still a long ways away from hermetic
> reproducible kernel builds I suspect, but my main worry is when people
> have multiple versions of a toolchain in their path, that only one is
> used.  Otherwise, it leads to spooky hard to reproduce bug reports.  I
> don't think I need to argue about build hermiticity, but it's
> important for user trust and verification.
>

So we need the Clang assembler for reproducible builds?

> 4. Improving toolchain portability of assembler in LLVM itself.
> There's plenty of subtle differences, but missing full on instructions
> (or are they psuedo's?) is pretty bad.
>

I don't think this point belongs in the 'why should we care about the
Clang assembler' list :-)

> I value the feedback from you, Russell, and Arnd even when I disagree.
> These are just my thoughts on *why* things are the way they are, FWIW.
> If there's thoughts on how we might better prioritize one thing over
> another, I would appreciate it.

I think the 'all legacy needs to die' attitude is not particularly
helpful here. In the 32-bit Linux/ARM community, there are many people
who care about older systems, and spend a lot of time on keeping
things in a working order on platforms that Google or ARM have stopped
caring about long ago.