[M680x0] Add ELF and Triple info

[m4yers]

Summary

This patch is part of a bigger one D50314. It adds M680x0 ELF and Triple
information.

[lebedev.ri]

Please add appropriate test coverage to unittests/ADT/TripleTest.cpp.

[lebedev.ri]

I'm not sure how ELF/relocation stuff should be tested, but i *think* it can also be split into a second review.
Though

llvm/test$ find -iname *Relocs*

does find some things.

[m4yers]

In D50858#1202964, @lebedev.ri wrote:

I'm not sure how ELF/relocation stuff should be tested, but i *think* it can also be split into a second review.
Though

llvm/test$ find -iname *Relocs*

does find some things.

There are tests for relocations in the main diff D50314 test/CodeGen/M680x0/OBJ/Relocations, but those require the full backend available. Aside from that I'm not really sure how to test them in a separate diff. For now they are just data copied from the m68k manual.

Please add appropriate test coverage to unittests/ADT/TripleTest.cpp.

Will do

[m4yers]

Add Triple tests

[glaubitz]

unittests/ADT/TripleTest.cpp

865

Is this a formatting error (tabs vs. spaces maybe)? The syntax highlighter shows a yellow block at the beginning of the line.

[m4yers]

unittests/ADT/TripleTest.cpp

865

It seems the diff tool assumes a space was copied from line 838... anyhow, there are only spaces in this diff.

[glaubitz]

@m4yers I think you need to add reviewers here as well, no?

[kristina]

LGTM, thank you for not forgetting to update the modulemap!

[kristina]

Do you have commit access? If not, I can land it for you, need a second to test it out with more configurations first though.

[lebedev.ri]

I think i lost track, was there some consensus on this 'support for m680x0' somewhere on the mailing list?
I don't dis-welcome this, just asking.

[glaubitz]

Hi Kristina!

Would be awesome if you could commit that for us!

Thanks a lot for your review!

[kristina]

In D50858#1233851, @lebedev.ri wrote:

I think i lost track, was there some consensus on this 'support for m680x0' somewhere on the mailing list?
I don't dis-welcome this, just asking.

I don't believe there was. I don't believe any objections to it were raised either however given how many diffs are blocked on this.

[kristina]

Build failure, x86_64 Linux, Modular, ThinLTO, clean cache:

/SourceCache/llvm-trunk-8.0.4116/lib/MC/MCExpr.cpp:200:8: error: use of undeclared identifier 'VK_GOTPC'; did you mean 'VK_GOT'?
  case VK_GOTPC: return "GOTPC";
       ^~~~~~~~
       VK_GOT
/SourceCache/llvm-trunk-8.0.4116/include/llvm/MC/MCExpr.h:172:5: note: 'VK_GOT' declared here
    VK_GOT,
    ^
/SourceCache/llvm-trunk-8.0.4116/lib/MC/MCExpr.cpp:200:8: error: duplicate case value 'VK_GOT'
  case VK_GOTPC: return "GOTPC";
       ^
/SourceCache/llvm-trunk-8.0.4116/lib/MC/MCExpr.cpp:197:8: note: previous case defined here
  case VK_GOT: return "GOT";
       ^
/SourceCache/llvm-trunk-8.0.4116/lib/MC/MCExpr.cpp:327:20: error: use of undeclared identifier 'VK_GOTPC'; did you mean 'VK_GOT'?
    .Case("gotpc", VK_GOTPC)
                   ^~~~~~~~
                   VK_GOT
/SourceCache/llvm-trunk-8.0.4116/include/llvm/MC/MCExpr.h:172:5: note: 'VK_GOT' declared here
    VK_GOT,
    ^
3 errors generated.

[kristina]

Did you by any chance leave out a file from this patch?

[kristina]

Also if possible can you resubmit all of these with context, it doesn't look like they have any and it's possible patch missed something when I applied them to run test builds. Let me know when that's been done, the current patches break the build, unless it's an issue on my end with my buildbots or misapplied patch due to missing context, it should be revised.

[kristina]

Also, sorry for the comment flurry, but would you mind bringing this up on llvm-dev as a proposed target? There isn't anything on there, and I was too hasty to accept it since adding a new target is a fairly significant change. I'd be happy to re-review it once the build is fixed and once there's some feedback from the development mailing list.

[glaubitz]

Hi Kristina!

Thanks a lot for your comments and review!

There was actually a discussion started on llvm-dev, see: lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html

Linux on m68k is very well maintained and there are also a maintained m68k port for NetBSD.

The community is very active and pretty large given the fact that the architecture is very old. But there are alternative implementations based on FPGAs and emulators, of course.

Adrian

[kristina]

Apologies, I couldn't find it when I tried. It seems good, and I'm happy to re-review it and land it once it's in a build-able/testable state. My only remaining issue is addressing the failed builds, if you can revise it, I'll rerun it and make sure it's all good since I understand this is a blocking patch for most of the other ones. Again I do apologize and I'm sorry it went unreviewed for so long.

[glaubitz]

No worries. Very glad it got finally picked up for review.

The original author is Artyom, so we better wait for him to rebase and fix the patches!

Again, thanks a lot for the review. Much appreciated!

[kristina]

Also, can I add that since this is a new target, it requires a code owner, could I ask that this is brought up with @chandlerc with regards to that on the mailing lists or even on IRC, since you will be taking responsibility for this (experimental) target and understand the implications of that?

[glaubitz]

I'd be very happy to support Artyom as a co-maintainer. I assume Artyom wants to be the code owner since he already stated, he wants to develop the code at LLVM upstream.

[chandlerc]

Before we add yet another experimental backend, I think it is somewhat important to know what the long-term user story is and the long-term maintenance story.

I'd love for some folks already active in the community, and especially actively maintaining parts of backends to have looked at the larger new backend effort here and to be supportive of it going in... Even an experimental backend adds significant maintenance burden on the larger community. We're already struggling to support and integrate the current experimental backends we have, and its not clear they are all on a healthy path to becoming non-experimental. I don't think we want eternally experimental backends, I think we should have a really clear path for backends to become 100% supported or be removed. So far, no one from the community has even commented on the llvm-dev thread for this. I think reviewing or landing patches is premature until these higher-order issues are sorted, which probably best happens on llvm-dev as the individual patches may not be a clear place to have that discussion.

Similarly, we have (and to an extent, continue to have) problems with experimental backends never having bots turned up to keep them tested and working. Is there a plan for build bots here?

I don't want to seem super negative about this particular backend -- I don't know anything about it and assume it is generally a good backend. And I have no opinions in any direction about the target. I also don't want to seem negative about the general idea of growing more backends. I think LLVM *should* be actively pursuing new backends where we have the community support for them.

However, I want to make sure that we actually have the necessary community support. Currently, I don't see any evidence of that community support on llvm-dev. I think that needs to be addressed before investing more energy in patches.

[glaubitz]

Hi Chandler!

Thanks a lot for your insight. I agree, testing and proper maintenance are crucial for a new backend and I am also very much aware of the responsibilities.

While I cannot vouch that this new backend will be perfectly maintained and issues are always fixed quickly, there is actually a build bot which regularly builds LLVM snapshots on a large number of targets and that is the build infrastructure in Debian.

As you can see here: https://buildd.debian.org/status/package.php?p=llvm-toolchain-snapshot&suite=sid , the latest SVN revision currently built is r340819, so I assume that's pretty new.

You can see the build logs by clicking the green "Installed" or "Build-Attempted" fields respectively. More build logs can be found in the right-most column.

The various branches are also being built regularly:

https://buildd.debian.org/status/package.php?p=llvm-toolchain-6.0&suite=sid
https://buildd.debian.org/status/package.php?p=llvm-toolchain-7&suite=sid

Other Linux distributions like Fedora or openSUSE are also providing publicly accessible build logs, although these distributions don't cover as many targets as Debian.

Again, I cannot promise to be the perfect maintainer, but we're doing our best in Debian downstream to find issues as quickly as possible and report them upstream as soon as they show up - and hopefully also help fixing them.

Thanks again for your input!

Adrian

[m4yers]

Add missed enum value

[m4yers]

Thanks @kristina for the review, I’ve updated the diff, now it should be buildable.

@chandlerc @glaubitz I'll move this discussion to the mailing list

[kristina]

Hi, I'll leave it in "Needs Review" state until there's some sort of clear consensus on the mailing lists, as far as I understand it you're backed by Debian CI infra, which means you at least have buildbots to ensure this back-end doesn't break or cause regressions in other parts of LLVM. I think as far as that part goes it is fine, but as Chandler explained, it's best to have an existing non-experimental back-end endorse you or getting some form of (even informal) downstream endorsement from Canonical or Debian that can be as simple as confirming you are able and have been maintaining this back-end downstream and that it has kept pace with the current development of LLVM. And as you mentioned yourself, that part is best left to the mailing lists. I would suggest discussing this over with at least one existing non-experimental backend owner at the very least regardless, you can find the list in CODE_OWNERS.txt. If there's some community interest and some form of endorsement (or heavy endorsement from one of the major downstream vendors), I'd be happy to re-review this. Leaving it open as I'll watch the lists and see how this goes and huge apologies for my hasty initial reply.

[glaubitz]

I was so much looking forward to this getting merged :-(.

[glaubitz]

How do we move forward now?

[kristina]

I think talking to the RISC-V back-end (@asb) over email owner would be one option and seeing if he's willing to back this, along with some official endorsement from downstream. There weren't many responses on the mailing lists from within the LLVM community and while you can bring the topic up again, I think the best course of action would be getting some support from downstream showing that there is a reasonable amount of interest in this backend within the Debian community (I assume there is since your CI is based there) as well as talking to @asb and getting his endorsement (seems to be the most suitable back-end similarity-wise). Other things that would help is showing that you've been keeping it up to date with the current development trunk of LLVM (I presume it is hosted downstream with Debian?). I'm sorry, I can't really give you anymore advice than this. Chandler has outlined the issue very well, in that code owners for back-ends have a huge responsibility since LLVM development moves at a fast pace and it's their responsibility their back-end doesn't break or end up causing build failures and other disruptions because of any affiliated people being absent, at which point it may flat out get removed. Unless you have worked things out this diff isn't really the place to discuss this, but I hope the advice is of some help.

Thank you.

[glaubitz]

Hi Kristina!

I will try to get in touch with @asb.

Thanks!
Adrian

[RKSimon]

@m4yers Abandon this now that the m68k target has landed?

include/llvm/ADT/Triple.h

enum ArchType {
     sparc,          // Sparc: sparc
     sparcv9,        // Sparcv9: Sparcv9
     sparcel,        // Sparc: (endianness = little). NB: 'Sparcle' is a CPU variant
     systemz,        // SystemZ: s390x
     tce,            // TCE (http://tce.cs.tut.fi/): tce
     tcele,          // TCE little endian (http://tce.cs.tut.fi/): tcele
     thumb,          // Thumb (little endian): thumb, thumbv.*
     thumbeb,        // Thumb (big endian): thumbeb
+    m680x0,         // m680x0: Motorola 680x0 family
     x86,            // X86: i[3-9]86
     x86_64,         // X86-64: amd64, x86_64
     xcore,          // XCore: xcore
     nvptx,          // NVPTX: 32-bit
     nvptx64,        // NVPTX: 64-bit
     le32,           // le32: generic little-endian 32-bit CPU (PNaCl)
     le64,           // le64: generic little-endian 64-bit CPU (PNaCl)
     amdil,          // AMDIL

include/llvm/BinaryFormat/ELF.h

 #include "ELFRelocs/AMDGPU.def"
 };
 
 // ELF Relocation types for BPF
 enum {
 #include "ELFRelocs/BPF.def"
 };
 
+// ELF Relocation types for M680x0
+enum {
+#include "ELFRelocs/m680x0.def"
+};
+
 #undef ELF_RELOC
 
 // Section header.
 struct Elf32_Shdr {
   Elf32_Word sh_name;      // Section name (index into string table)
   Elf32_Word sh_type;      // Section type (SHT_*)
   Elf32_Word sh_flags;     // Section flags (SHF_*)
   Elf32_Addr sh_addr;      // Address where section is to be loaded

include/llvm/BinaryFormat/ELFRelocs/m680x0.def

+
+#ifndef ELF_RELOC
+#error "ELF_RELOC must be defined"
+#endif
+
+ELF_RELOC (R_M680x0_NONE,          0)  /* No reloc */
+ELF_RELOC (R_M680x0_32,            1)  /* Direct 32 bit  */
+ELF_RELOC (R_M680x0_16,            2)  /* Direct 16 bit  */
+ELF_RELOC (R_M680x0_8,             3)  /* Direct 8 bit  */
+ELF_RELOC (R_M680x0_PC32,          4)  /* PC relative 32 bit */
+ELF_RELOC (R_M680x0_PC16,          5)  /* PC relative 16 bit */
+ELF_RELOC (R_M680x0_PC8,           6)  /* PC relative 8 bit */
+ELF_RELOC (R_M680x0_GOTPCREL32,    7)  /* 32 bit PC relative GOT entry */
+ELF_RELOC (R_M680x0_GOTPCREL16,    8)  /* 16 bit PC relative GOT entry */
+ELF_RELOC (R_M680x0_GOTPCREL8,     9)  /* 8 bit PC relative GOT entry */
+ELF_RELOC (R_M680x0_GOTOFF32,      10) /* 32 bit GOT offset */
+ELF_RELOC (R_M680x0_GOTOFF16,      11) /* 16 bit GOT offset */
+ELF_RELOC (R_M680x0_GOTOFF8,       12) /* 8 bit GOT offset */
+ELF_RELOC (R_M680x0_PLT32,         13) /* 32 bit PC relative PLT address */
+ELF_RELOC (R_M680x0_PLT16,         14) /* 16 bit PC relative PLT address */
+ELF_RELOC (R_M680x0_PLT8,          15) /* 8 bit PC relative PLT address */
+ELF_RELOC (R_M680x0_PLTOFF32,      16) /* 32 bit PLT offset */
+ELF_RELOC (R_M680x0_PLTOFF16,      17) /* 16 bit PLT offset */
+ELF_RELOC (R_M680x0_PLTOFF8,       18) /* 8 bit PLT offset */
+ELF_RELOC (R_M680x0_COPY,          19) /* Copy symbol at runtime */
+ELF_RELOC (R_M680x0_GLOB_DAT,      20) /* Create GOT entry */
+ELF_RELOC (R_M680x0_JMP_SLOT,      21) /* Create PLT entry */
+ELF_RELOC (R_M680x0_RELATIVE,      22) /* Adjust by program base */
+/* These are GNU extensions to enable C++ vtable garbage collection.  */
+ELF_RELOC (R_M680x0_GNU_VTINHERIT, 23)
+ELF_RELOC (R_M680x0_GNU_VTENTRY,   24)
+/* TLS static relocations.  */
+ELF_RELOC (R_M680x0_TLS_GD32,      25)
+ELF_RELOC (R_M680x0_TLS_GD16,      26)
+ELF_RELOC (R_M680x0_TLS_GD8,       27)
+ELF_RELOC (R_M680x0_TLS_LDM32,     28)
+ELF_RELOC (R_M680x0_TLS_LDM16,     29)
+ELF_RELOC (R_M680x0_TLS_LDM8,      30)
+ELF_RELOC (R_M680x0_TLS_LDO32,     31)
+ELF_RELOC (R_M680x0_TLS_LDO16,     32)
+ELF_RELOC (R_M680x0_TLS_LDO8,      33)
+ELF_RELOC (R_M680x0_TLS_IE32,      34)
+ELF_RELOC (R_M680x0_TLS_IE16,      35)
+ELF_RELOC (R_M680x0_TLS_IE8,       36)
+ELF_RELOC (R_M680x0_TLS_LE32,      37)
+ELF_RELOC (R_M680x0_TLS_LE16,      38)
+ELF_RELOC (R_M680x0_TLS_LE8,       39)
+ELF_RELOC (R_M680x0_TLS_DTPMOD32,  40)
+ELF_RELOC (R_M680x0_TLS_DTPREL32,  41)
+ELF_RELOC (R_M680x0_TLS_TPREL32,   42)

include/llvm/Object/ELFObjectFile.h

 }
 
 template <class ELFT>
 StringRef ELFObjectFile<ELFT>::getFileFormatName() const {
   bool IsLittleEndian = ELFT::TargetEndianness == support::little;
   switch (EF.getHeader()->e_ident[ELF::EI_CLASS]) {
   case ELF::ELFCLASS32:
     switch (EF.getHeader()->e_machine) {
+    case ELF::EM_68K:
+      return "ELF32-M680x0";
     case ELF::EM_386:
       return "ELF32-i386";
     case ELF::EM_IAMCU:
       return "ELF32-iamcu";
     case ELF::EM_X86_64:
       return "ELF32-x86-64";
     case ELF::EM_ARM:
       return (IsLittleEndian ? "ELF32-arm-little" : "ELF32-arm-big");
default:
     // FIXME: Proper error handling.
     report_fatal_error("Invalid ELFCLASS!");
   }
 }
 
 template <class ELFT> Triple::ArchType ELFObjectFile<ELFT>::getArch() const {
   bool IsLittleEndian = ELFT::TargetEndianness == support::little;
   switch (EF.getHeader()->e_machine) {
+  case ELF::EM_68K:
+    return Triple::m680x0;
   case ELF::EM_386:
   case ELF::EM_IAMCU:
     return Triple::x86;
   case ELF::EM_X86_64:
     return Triple::x86_64;
   case ELF::EM_AARCH64:
     return IsLittleEndian ? Triple::aarch64 : Triple::aarch64_be;
   case ELF::EM_ARM:

include/llvm/module.modulemap

module LLVM_BinaryFormat {
     textual header "BinaryFormat/ELFRelocs/Lanai.def"
     textual header "BinaryFormat/ELFRelocs/Mips.def"
     textual header "BinaryFormat/ELFRelocs/PowerPC64.def"
     textual header "BinaryFormat/ELFRelocs/PowerPC.def"
     textual header "BinaryFormat/ELFRelocs/RISCV.def"
     textual header "BinaryFormat/ELFRelocs/Sparc.def"
     textual header "BinaryFormat/ELFRelocs/SystemZ.def"
     textual header "BinaryFormat/ELFRelocs/x86_64.def"
+    textual header "BinaryFormat/ELFRelocs/m680x0.def"
     textual header "BinaryFormat/WasmRelocs.def"
 }
 
 module LLVM_Config { requires cplusplus umbrella "Config" module * { export * } }
 
 module LLVM_DebugInfo {
   requires cplusplus
   module DIContext { header "DebugInfo/DIContext.h" export * }

lib/MC/MCExpr.cpp

StringRef MCSymbolRefExpr::getVariantKindName(VariantKind Kind) {
   case VK_Invalid: return "<<invalid>>";
   case VK_None: return "<<none>>";
 
   case VK_DTPOFF: return "DTPOFF";
   case VK_DTPREL: return "DTPREL";
   case VK_GOT: return "GOT";
   case VK_GOTOFF: return "GOTOFF";
   case VK_GOTREL: return "GOTREL";
+  case VK_GOTPC: return "GOTPC";
   case VK_GOTPCREL: return "GOTPCREL";
   case VK_GOTTPOFF: return "GOTTPOFF";
   case VK_INDNTPOFF: return "INDNTPOFF";
   case VK_NTPOFF: return "NTPOFF";
   case VK_GOTNTPOFF: return "GOTNTPOFF";
   case VK_PLT: return "PLT";
   case VK_TLSGD: return "TLSGD";
   case VK_TLSLD: return "TLSLD";

 MCSymbolRefExpr::VariantKind
 MCSymbolRefExpr::getVariantKindForName(StringRef Name) {
   return StringSwitch<VariantKind>(Name.lower())
     .Case("dtprel", VK_DTPREL)
     .Case("dtpoff", VK_DTPOFF)
     .Case("got", VK_GOT)
     .Case("gotoff", VK_GOTOFF)
     .Case("gotrel", VK_GOTREL)
+    .Case("gotpc", VK_GOTPC)
     .Case("gotpcrel", VK_GOTPCREL)
     .Case("gottpoff", VK_GOTTPOFF)
     .Case("indntpoff", VK_INDNTPOFF)
     .Case("ntpoff", VK_NTPOFF)
     .Case("gotntpoff", VK_GOTNTPOFF)
     .Case("plt", VK_PLT)
     .Case("tlscall", VK_TLSCALL)
     .Case("tlsdesc", VK_TLSDESC)

lib/Object/ELF.cpp

#define STRINGIFY_ENUM_CASE(ns, name)                                          \
   case ns::name:                                                               \
     return #name;
 
 #define ELF_RELOC(name, value) STRINGIFY_ENUM_CASE(ELF, name)
 
 StringRef llvm::object::getELFRelocationTypeName(uint32_t Machine,
                                                  uint32_t Type) {
   switch (Machine) {
+  case ELF::EM_68K:
+    switch (Type) {
+#include "llvm/BinaryFormat/ELFRelocs/m680x0.def"
+    default:
+      break;
+    }
+    break;
   case ELF::EM_X86_64:
     switch (Type) {
 #include "llvm/BinaryFormat/ELFRelocs/x86_64.def"
     default:
       break;
     }
     break;
   case ELF::EM_386:

lib/ObjectYAML/ELFYAML.cpp

 #include "llvm/BinaryFormat/ELFRelocs/Lanai.def"
     break;
   case ELF::EM_AMDGPU:
 #include "llvm/BinaryFormat/ELFRelocs/AMDGPU.def"
     break;
   case ELF::EM_BPF:
 #include "llvm/BinaryFormat/ELFRelocs/BPF.def"
     break;
+  case ELF::EM_68K:
+#include "llvm/BinaryFormat/ELFRelocs/m680x0.def"
+    break;
   default:
     llvm_unreachable("Unsupported architecture");
   }
 #undef ELF_RELOC
   IO.enumFallback<Hex32>(Value);
 }
 
 void ScalarEnumerationTraits<ELFYAML::MIPS_AFL_REG>::enumeration(

lib/Support/Triple.cpp

StringRef Triple::getArchTypeName(ArchType Kind) {
   case sparc:          return "sparc";
   case sparcv9:        return "sparcv9";
   case sparcel:        return "sparcel";
   case systemz:        return "s390x";
   case tce:            return "tce";
   case tcele:          return "tcele";
   case thumb:          return "thumb";
   case thumbeb:        return "thumbeb";
+  case m680x0:         return "m680x0";
   case x86:            return "i386";
   case x86_64:         return "x86_64";
   case xcore:          return "xcore";
   case nvptx:          return "nvptx";
   case nvptx64:        return "nvptx64";
   case le32:           return "le32";
   case le64:           return "le64";
   case amdil:          return "amdil";
StringRef Triple::getArchTypePrefix(ArchType Kind) {
   case bpfeb:       return "bpf";
 
   case sparcv9:
   case sparcel:
   case sparc:       return "sparc";
 
   case systemz:     return "s390";
 
+  case m680x0:      return "m680x0";
+
   case x86:
   case x86_64:      return "x86";
 
   case xcore:       return "xcore";
 
   // NVPTX intrinsics are namespaced under nvvm.
   case nvptx:       return "nvvm";
   case nvptx64:     return "nvvm";
return StringSwitch<Triple::ArchType>(Name)
     .Case("sparc", sparc)
     .Case("sparcel", sparcel)
     .Case("sparcv9", sparcv9)
     .Case("systemz", systemz)
     .Case("tce", tce)
     .Case("tcele", tcele)
     .Case("thumb", thumb)
     .Case("thumbeb", thumbeb)
+    .Case("m680x0", m680x0)
     .Case("x86", x86)
     .Case("x86-64", x86_64)
     .Case("xcore", xcore)
     .Case("nvptx", nvptx)
     .Case("nvptx64", nvptx64)
     .Case("le32", le32)
     .Case("le64", le64)
     .Case("amdil", amdil)
static Triple::ArchType parseArch(StringRef ArchName) {
   auto AT = StringSwitch<Triple::ArchType>(ArchName)
     .Cases("i386", "i486", "i586", "i686", Triple::x86)
     // FIXME: Do we need to support these?
     .Cases("i786", "i886", "i986", Triple::x86)
     .Cases("amd64", "x86_64", "x86_64h", Triple::x86_64)
     .Cases("powerpc", "ppc", "ppc32", Triple::ppc)
     .Cases("powerpc64", "ppu", "ppc64", Triple::ppc64)
     .Cases("powerpc64le", "ppc64le", Triple::ppc64le)
+    .Case("m680x0", Triple::m680x0)
     .Case("xscale", Triple::arm)
     .Case("xscaleeb", Triple::armeb)
     .Case("aarch64", Triple::aarch64)
     .Case("aarch64_be", Triple::aarch64_be)
     .Case("arc", Triple::arc)
     .Case("arm64", Triple::aarch64)
     .Case("arm", Triple::arm)
     .Case("armeb", Triple::armeb)

 }
 
 static Triple::ObjectFormatType getDefaultFormat(const Triple &T) {
   switch (T.getArch()) {
   case Triple::UnknownArch:
   case Triple::aarch64:
   case Triple::arm:
   case Triple::thumb:
+  case Triple::m680x0:
   case Triple::x86:
   case Triple::x86_64:
     if (T.isOSDarwin())
       return Triple::MachO;
     else if (T.isOSWindows())
       return Triple::COFF;
     return Triple::ELF;
 
static unsigned getArchPointerBitWidth(llvm::Triple::ArchType Arch) {
   case llvm::Triple::r600:
   case llvm::Triple::riscv32:
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::tce:
   case llvm::Triple::tcele:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb:
+  case llvm::Triple::m680x0:
   case llvm::Triple::x86:
   case llvm::Triple::xcore:
   case llvm::Triple::amdil:
   case llvm::Triple::hsail:
   case llvm::Triple::spir:
   case llvm::Triple::kalimba:
   case llvm::Triple::lanai:
   case llvm::Triple::shave:
Triple Triple::get32BitArchVariant() const {
   case Triple::riscv32:
   case Triple::sparc:
   case Triple::sparcel:
   case Triple::tce:
   case Triple::tcele:
   case Triple::thumb:
   case Triple::thumbeb:
   case Triple::x86:
+  case Triple::m680x0:
   case Triple::xcore:
   case Triple::lanai:
   case Triple::shave:
   case Triple::wasm32:
   case Triple::renderscript32:
     // Already 32-bit.
     break;
 
Triple Triple::get64BitArchVariant() const {
   case Triple::kalimba:
   case Triple::lanai:
   case Triple::msp430:
   case Triple::nios2:
   case Triple::r600:
   case Triple::tce:
   case Triple::tcele:
   case Triple::xcore:
+  case Triple::m680x0:
   case Triple::sparcel:
   case Triple::shave:
     T.setArch(UnknownArch);
     break;
 
   case Triple::aarch64:
   case Triple::aarch64_be:
   case Triple::bpfel:
if (isLittleEndian())
     return T;
 
   switch (getArch()) {
   case Triple::UnknownArch:
   case Triple::lanai:
   case Triple::ppc:
   case Triple::sparcv9:
   case Triple::systemz:
+  case Triple::m680x0:
 
   // ARM is intentionally unsupported here, changing the architecture would
   // drop any arch suffixes.
   case Triple::armeb:
   case Triple::thumbeb:
     T.setArch(UnknownArch);
     break;
 

unittests/ADT/TripleTest.cpp

TEST(TripleTest, ParsedIDs) {
   EXPECT_EQ(Triple::GNUEABI, T.getEnvironment());
 
   T = Triple("aarch64-oe-linux");
   EXPECT_EQ(Triple::aarch64, T.getArch());
   EXPECT_EQ(Triple::OpenEmbedded, T.getVendor());
   EXPECT_EQ(Triple::Linux, T.getOS());
   EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
 
+  T = Triple("m680x0");
+  EXPECT_EQ(Triple::m680x0, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+  EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
+
+  T = Triple("m680x0-unknown-unknown");
+  EXPECT_EQ(Triple::m680x0, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+  EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
+
+  T = Triple("m680x0-unknown-linux");
+  EXPECT_EQ(Triple::m680x0, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::Linux, T.getOS());
+  EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
+
   T = Triple("huh");
   EXPECT_EQ(Triple::UnknownArch, T.getArch());
 }
 
 static std::string Join(StringRef A, StringRef B, StringRef C) {
   std::string Str = A;
   Str += '-';
   Str += B;
TEST(TripleTest, BitWidthPredicates) {
   EXPECT_FALSE(T.isArch16Bit());
   EXPECT_TRUE(T.isArch32Bit());
   EXPECT_FALSE(T.isArch64Bit());
 
   T.setArch(Triple::riscv64);
   EXPECT_FALSE(T.isArch16Bit());
   EXPECT_FALSE(T.isArch32Bit());
   EXPECT_TRUE(T.isArch64Bit());
+
+  T.setArch(Triple::m680x0);
+  EXPECT_FALSE(T.isArch16Bit());
+  EXPECT_TRUE(T.isArch32Bit());
+  EXPECT_FALSE(T.isArch64Bit());
 }
 
 TEST(TripleTest, BitWidthArchVariants) {
   Triple T;
   EXPECT_EQ(Triple::UnknownArch, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::UnknownArch, T.get64BitArchVariant().getArch());
 
   T.setArch(Triple::UnknownArch);
TEST(TripleTest, BitWidthArchVariants) {
 
   T.setArch(Triple::systemz);
   EXPECT_EQ(Triple::UnknownArch, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::systemz, T.get64BitArchVariant().getArch());
 
   T.setArch(Triple::xcore);
   EXPECT_EQ(Triple::xcore, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::UnknownArch, T.get64BitArchVariant().getArch());
+
+  T.setArch(Triple::m680x0);
+  EXPECT_EQ(Triple::m680x0, T.get32BitArchVariant().getArch());
+  EXPECT_EQ(Triple::UnknownArch, T.get64BitArchVariant().getArch());
 }
 
 TEST(TripleTest, EndianArchVariants) {
   Triple T;
   EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
 
   T.setArch(Triple::UnknownArch);
TEST(TripleTest, EndianArchVariants) {
 
   T.setArch(Triple::le32);
   EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::le32, T.getLittleEndianArchVariant().getArch());
 
   T.setArch(Triple::le64);
   EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::le64, T.getLittleEndianArchVariant().getArch());
+
+  T.setArch(Triple::m680x0);
+  EXPECT_EQ(Triple::m680x0, T.getBigEndianArchVariant().getArch());
+  EXPECT_EQ(Triple::UnknownArch, T.getLittleEndianArchVariant().getArch());
 }
 
 TEST(TripleTest, getOSVersion) {
   Triple T;
   unsigned Major, Minor, Micro;
 
   T = Triple("i386-apple-darwin9");
   EXPECT_TRUE(T.isMacOSX());
TEST(TripleTest, FileFormat) {
   EXPECT_EQ(Triple::Wasm, Triple("wasm32-unknown-unknown").getObjectFormat());
   EXPECT_EQ(Triple::Wasm, Triple("wasm64-unknown-unknown").getObjectFormat());
 
   EXPECT_EQ(Triple::Wasm,
             Triple("wasm32-unknown-unknown-wasm").getObjectFormat());
   EXPECT_EQ(Triple::Wasm,
             Triple("wasm64-unknown-unknown-wasm").getObjectFormat());
 
+  EXPECT_EQ(Triple::ELF, Triple("m680x0-unknown-linux").getObjectFormat());
+  EXPECT_EQ(Triple::ELF, Triple("m680x0-unknown-unknown").getObjectFormat());
+
   Triple MSVCNormalized(Triple::normalize("i686-pc-windows-msvc-elf"));
   EXPECT_EQ(Triple::ELF, MSVCNormalized.getObjectFormat());
 
   Triple GNUWindowsNormalized(Triple::normalize("i686-pc-windows-gnu-elf"));
   EXPECT_EQ(Triple::ELF, GNUWindowsNormalized.getObjectFormat());
 
   Triple CygnusNormalised(Triple::normalize("i686-pc-windows-cygnus-elf"));
   EXPECT_EQ(Triple::ELF, CygnusNormalised.getObjectFormat());