[lld] [ELF,SPARC] Add the 32-bit SPARC target (PR #228200)

[Imre Kaloz via llvm-commits]

kaloz wrote:

> Rust doesn't need lld for SPARC. sparc-unknown-linux-gnu is Tier 3 and links through the system cc with GNU ld. The dependency is on the Sparc backend, which is already in-tree. A QEMU sun4m bot is helpful as a signal, but it doesn't change who fixes lld when it goes red. Dropping #228201 limits the target to pure-V8 objects, which leaves a downstream musl port as the only user. Even the work you and a few others are putting into sun4m is real, that effort doesn't make a community large enough to justify an in-tree target.
> 
> On #228197 and other PRs you have planned as first-time llvm-project contributor: I don't object to the tools; I use them myself. The problem is what heavily generated patches do to the social system around code. The effort it took to write a patch used to be a commitment signal. Now the cost shifts to the maintainer, who has to review code its author may only half understand. I am not sure many reviewers would likely review heavily assisted patches. With the same tools, a maintainer who knows the code can produce a better patch. For components maintained as volunteer work, maintainer time is the bottleneck, and LLVM's AI Tool Use Policy calls such patches extractive for that reason. If V9 TLS GD/LD support is needed, I'll need them or handle it myself, as I did for the rest of the SPARCV9 target.

Fair point on Rust, it only needs the backend.

On the AI concerns, which I take seriously: I'm new to LLVM, and I used AI assistance to work in a codebase I know less well than the kernel. It wasn't used to generate code blindly. Every change follows the SPARC architecture manuals and the SPARC psABI, matches GNU ld's behaviour, and comes with tests. I reviewed all of it and ran the linked output on sun4m under QEMU. That doesn't remove the review cost you describe, but I can answer questions on any part of it.

I'll take the broader question of in-tree 32-bit SPARC support to Discourse and convert this PR and #228201 to drafts in the meantime. For #228197, feel free to reuse the tests if you do V9 TLS GD/LD yourself; I'll close mine.

> #228198 is a Sparc backend change, so that's for @koachan.

@koachan, could you please take a look at #228198 when you have time? It's a small delay-slot fix in the Sparc backend with a sparc64 test.

https://github.com/llvm/llvm-project/pull/228200