[clang] [compiler-rt] [llvm] Add SuperH (1-4a) target (PR #181287)

[Alex Rønne Petersen via cfe-commits]

================
@@ -80,6 +80,8 @@ class Triple {
     riscv64,     // RISC-V (64-bit, little endian): riscv64
     riscv32be,   // RISC-V (32-bit, big endian): riscv32be
     riscv64be,   // RISC-V (64-bit, big endian): riscv64be
+    sh,          // SuperH (big endian): sh
+    shl,         // SuperH (little endian): shl
----------------
alexrp wrote:

>From what I can gather, GNU triples make endianness for SH a mess where there is no consistent spelling for little and big endian that works for all possible SH versions and OS targets, and the default endianness when none is given depends on the other triple components. Just spectacular stuff all around.

I think we really should resist making the meaning of the arch component depend on the rest as GNU did. But that raises the question of what plain `sh` should mean. Some `sh` defaults in GNU triples:

* `sh-elf`: big
* `sh-*-netbsd*`: big
* `sh-*-rtems*`: big
* `sh-superh-elf`: little
* `sh-linux`: little
* `sh-*-openbsd*`: little (in OpenBSD's in-tree fork)

I think the winning move is to not play, i.e. require the triple to be explicit about endianness. It's a break from GCC, but I think that's extremely justified by the mess GNU have created for themselves here.

So FWIW, my concrete suggestion is:

* Rename the `sh` enum member to `shb`.
* Parse `sh[cpu]<l|le|el>` as little endian.
* Parse `sh[cpu]<b|be|eb>` as big endian.
* `cpu` is optional and can be one of: `1`, `2`, `2a`, `2e`, `3`, `3e`, `4`, `4a`
    * `SubArchType` seems like the natural representation for these.
* Reject plain `sh[cpu]` in triple parsing.
    * Bonus points: Make Clang give a helpful error suggesting the explicit endianness form.

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