Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Please sync past 3a1cb362370d223e09899d234726e15b52327b0e: the patch accidentally removes isDriverKit.
Looking at existing cases of comparisons with Triple::sparc and Triple::sparcv9, I guess we should have isSPARC32 and isSPARC64, too, like isMIPS32/isMIPS64 and isPPC32/isPPC64. When switching to isSPARC* from existing Triple::sparc* comparisons, one will have to be extra careful if they are meant to mean SPARC in general or 32-bit SPARC in particular. little-endian SPARC is another beast altogether: I didn't even know it existed beyond the ability of SPARCV9 CPUs to partially run in LE mode, so it will be hard to tell if LE SPARC is to be included. I guess only code review and testing by interested parties can tell.
llvm/include/llvm/ADT/Triple.h | ||
---|---|---|
829 | I'd go for isSPARC instead: SPARC is an acronym, like MIPS, although LLVM is anything but consistent about the correct capitalization. |
llvm/include/llvm/ADT/Triple.h | ||
---|---|---|
829 | Thanks for the comment, I fixed it. |
@ro
Since sparcv9 is Bi-endianness (https://en.wikipedia.org/wiki/Endianness#Bi-endianness), I add "sparcv9el" like on MIPS. If it is not OK, I can delete it.
Could I do the switching to isSPARC* from existing Triple::sparc* in another patch?
I don't think this makes sense. No one runs SPARCv9 with little endian.
Not only that: this isn't a full fledged little-endian mode like mipsel. See "Oracle SPARC Architecture 2015", p.20:
3.3.1.2 Addressing Conventions [...] The Oracle SPARC Architecture also supports little-endian byte order for data accesses only: the address of a quadword, doubleword, word, or halfword is the address of its least significant byte. Increasing the address means increasing the significance of the data unit being accessed.
Could I do the switching to isSPARC* from existing Triple::sparc* in another patch?
Given the evaluation and testing requirements I'd mentioned, I guess it's better to start using isSPARC* for new or modified code right now, but handle existing comparisons to Triple::sparc* separately. I don't think that's your duty, though. You've done way enough already. Thanks.
llvm/include/llvm/ADT/Triple.h | ||
---|---|---|
829 | I think all those clang-format reformatting suggestions should be ignored: while they might be appropriate for new code, the new methods would be formatted differently from every other one in this file. |
clang-format: please reformat the code
102 diff lines are omitted. See full path.