================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
