Triple: Fix handling of macos with unexpected target arches

[arsenm]

Some tools with a specified target arch, but no full triple default to the host triple. On macos hosts, this would then force using macho on targets that didn't expect it, resulting in assertions.

We should also probably emit explicit errors if the object format is specified on targets which don't handle it.

[llvm-beanz]

I think this is the correct change, but I'm sure Apple has some out-of-tree code that will likely be impacted.

cc: @lhames, @dsandersllvm, @rudkx. Apologies I don't know Aditya, or Charu's GitHub accounts and the autocomplete is failing me.

[llvm-beanz]

nit: should we combine this with the two if's above and make it a switch on the OS (Windows, UEFI and Darwin are all OS bits)?

[arsenm]

It kind of works but isOSDarwin covers a few too many things:

return isMacOSX() || isiOS() || isWatchOS() || isDriverKit();

  bool isiOS() const {
    return getOS() == Triple::IOS || isTvOS();
  }

[nico]

@MaskRay FYI (since you did a bunch of march -> mtriple changes that were necessary before this).

[MaskRay]

@MaskRay FYI (since you did a bunch of march -> mtriple changes that were necessary before this).

Thanks for CCing me!

  EXPECT_EQ(Triple::ELF, Triple("amdgcn-apple-macosx").getObjectFormat());
  EXPECT_EQ(Triple::ELF, Triple("r600-apple-macosx").getObjectFormat());

I know that this serves as a change detector about the current behavior and not an endorsement of whether this makes sense.

However, ELF does not make more sense here. If we want to unsupport some unexpected target triples, I feel that the change should be made at an upper level, or change the return value to UnknownObjectFormat.

If the issue is {opt,llc} -march=..., fix them to switch to -mtriple= instead.

[MaskRay]

Created #75982 to change AMDGPU tests to use -mtriple=