[LLVM][Triple] Add an argument to specify canonical form to `Triple::normalize` (#122935)

Currently, the output of `Triple::normalize` can vary depending on how the
`Triple` object is constructed, p

[LLVM][Triple] Add an argument to specify canonical form to `Triple::normalize` (#122935)

Currently, the output of `Triple::normalize` can vary depending on how the
`Triple` object is constructed, producing a 3-field, 4-field, or even 5-field
string. However, there is no way to control the format of the output, as all
forms are considered canonical according to the LangRef.

This lack of control can be inconvenient when a specific format is required. To
address this, this PR introduces an argument to specify the desired format (3,
4, or 5 identifiers), with the default set to none to maintain the current
behavior. If the requested format requires more components than are available in
the actual `Data`, `"unknown"` is appended as needed.

show more ...

[Triple] Ignore the vendor field for MinGW, wrt LTO/IR compatibility (#122801)

For MinGW environments, the regular C/C++ toolchains usually use "w64"
for the vendor field in triples, while Rust too

[Triple] Ignore the vendor field for MinGW, wrt LTO/IR compatibility (#122801)

For MinGW environments, the regular C/C++ toolchains usually use "w64"
for the vendor field in triples, while Rust toolchains usually use "pc"
in the vendor field.

The differences in the vendor field have no bearing on whether the IR is
compatible on this platform. (This probably goes for most other OSes as
well, but limiting the scope of the change to the specific case.)

Add a unit test for the isCompatibleWith, including some existing test
cases found in existing tests.

show more ...

[LLVM] Add Intel vendor in Triple (#120250)

We plan to make use of this in SPIR-V-based OpenMP offloading, for which
there is already an initial patch in review.

Signed-off-by: Sarnie, Nick <nic

[LLVM] Add Intel vendor in Triple (#120250)

We plan to make use of this in SPIR-V-based OpenMP offloading, for which
there is already an initial patch in review.

Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>

show more ...

[LLVM] Add environment triple for 'llvm' (#117218)

Summary:
The LLVM C library is an in-development environment for running
executables on various systems. Similarly how we have `-gnu` to indicate
t

[LLVM] Add environment triple for 'llvm' (#117218)

Summary:
The LLVM C library is an in-development environment for running
executables on various systems. Similarly how we have `-gnu` to indicate
that we are using a GNU toolchain we should support `-llvm` to indicate
the LLVM C library. This patch only adds the basic support for the
triple and does not do any necessary clang changes to handle compiling
with it.

Fixes https://github.com/llvm/llvm-project/issues/117251

show more ...

[Triple] Make mipsel-*-windows-* use COFF files by default (#107809)

Windows NT/MIPS and Windows CE/MIPS always used COFF format.

This is an extract of PR #107744.

[LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (#111302)

Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `ti

[LLVM] [Clang] Support for Gentoo `*t64` triples (64-bit time_t ABIs) (#111302)

Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.

An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.

show more ...

[llvm][Triple] Add `Environment` members and parsing for glibc/musl parity. (#107664)

This adds support for:

* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP6

[llvm][Triple] Add `Environment` members and parsing for glibc/musl parity. (#107664)

This adds support for:

* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)

As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.

I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.

Note: I don't have commit access.

show more ...

[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)

When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following

[PAC][Driver] Support `pauthtest` ABI for AArch64 Linux triples (#97237)

When `pauthtest` is either passed as environment part of AArch64 Linux
triple
or passed via `-mabi=`, enable the following ptrauth flags:

- `intrinsics`;
- `calls`;
- `returns`;
- `auth-traps`;
- `vtable-pointer-address-discrimination`;
- `vtable-pointer-type-discrimination`;
- `init-fini`.

Some related stuff is still subject to change, and the ABI itself might
be changed, so end users are not expected to use this and the ABI name
has 'test' suffix.

If `-mabi=pauthtest` option is used, it's normalized to effective
triple.

When the environment part of the effective triple is `pauthtest`, try
to use `aarch64-linux-pauthtest` as multilib directory.

The following is not supported:
- combination of `pauthtest` ABI with any branch protection scheme
except BTI;
- explicit set of environment part of the triple to a value different
from `pauthtest` in combination with `-mabi=pauthtest`;
- usage on non-Linux OS.

---------

Co-authored-by: Anatoly Trosinenko <atrosinenko@accesssoftek.com>

show more ...

[DXIL] Set DXIL Version in DXIL target triple based on shader model version (#91407)

This change set restores commit 080978dd2067d0c9ea7e229aa7696c2480d89ef1 that was reverted to address ASAN
failu

[DXIL] Set DXIL Version in DXIL target triple based on shader model version (#91407)

This change set restores commit 080978dd2067d0c9ea7e229aa7696c2480d89ef1 that was reverted to address ASAN
failures and includes a fix for the ASAN failures.

Following is the description of the change:

An earlier commit provided a way to decouple DXIL version from Shader
Model version by representing the DXIL version as `SubArch` in the DXIL
Target Triple and adding corresponding valid DXIL Arch types.

This change constructs DXIL target triple with DXIL version that is
deduced from Shader Model version specified in the following scenarios:

1. When compilation target profile is specified:
For e.g., DXIL target triple `dxilv1.8-unknown-shader6.8-library` is
constructed when `-T lib_6_8` is specified.
2. When DXIL target triple without DXIL version is specified:
For e.g., DXIL target triple `dxilv1.8-pc-shadermodel6.8-library` is
constructed when `-mtriple=dxil-pc-shadermodel6.8-library` is specified.

Updated relevant HLSL tests that check for target triple.

show more ...

[DirectX backend] emits metadata for DXIL version. (#88350)

Emit named metadata "dx.version" for DXIL version.

Default to DXIL 1.0

Revert "[DirectX][DXIL] Set DXIL Version in DXIL target triple based on shader model version" (#91290)

Reverts llvm/llvm-project#90809

Need to investigate ASAN failures.

[DirectX][DXIL] Set DXIL Version in DXIL target triple based on shader model version (#90809)

An earlier commit provided a way to decouple DXIL version from Shader
Model version by representing the

[DirectX][DXIL] Set DXIL Version in DXIL target triple based on shader model version (#90809)

An earlier commit provided a way to decouple DXIL version from Shader
Model version by representing the DXIL version as `SubArch` in the DXIL
Target Triple and adding corresponding valid DXIL Arch types.

This change constructs DXIL target triple with DXIL version that is
deduced from Shader Model version specified in the following scenarios:

1. When compilation target profile is specified:
For e.g., DXIL target triple `dxilv1.8-unknown-shader6.8-library` is
constructed when `-T lib_6_8` is specified.
2. When DXIL target triple without DXIL version is specified:
For e.g., DXIL target triple `dxilv1.8-pc-shadermodel6.8-library` is
constructed when `-mtriple=dxil-pc-shadermodel6.8-library` is specified.

Updated relevant HLSL tests that check for target triple.

Validated that Clang (`check-clang`) and LLVM (`check-llvm`) regression
tests pass.

show more ...

Triple::normalize: Use none as OS for XX-none-ABI (#89638)

When parsing a 3-component triple, after we determine Arch and Env, if
the middle component is "none", treat it as OS instead of Vendor.

Triple::normalize: Use none as OS for XX-none-ABI (#89638)

When parsing a 3-component triple, after we determine Arch and Env, if
the middle component is "none", treat it as OS instead of Vendor.

See:
https://discourse.llvm.org/t/rfc-baremetal-target-triple-normalization/78524
Fixes: #89582.

show more ...

[DXIL] Add DXIL SubArch to correspond to version number (#89125)

This change is in line with similar notation in SPIRV.

Decoupling version numbering of DXIL and of Shader Model is intended to
e

[DXIL] Add DXIL SubArch to correspond to version number (#89125)

This change is in line with similar notation in SPIRV.

Decoupling version numbering of DXIL and of Shader Model is intended to
enable accurate specification of DXIL features that can be targeted by
different Shader Model versions.

show more ...

[TargetParser] Expose Triple::getArchPointerBitWidth. (#82086)

The getArchPointerBitWidth method provides direct access to the pointer
size for arithmetic or switch statements, instead of requiring

[TargetParser] Expose Triple::getArchPointerBitWidth. (#82086)

The getArchPointerBitWidth method provides direct access to the pointer
size for arithmetic or switch statements, instead of requiring clients
to use the isArch16Bit / isArch32Bit / isArch64Bit predicates.

show more ...

[HLSL][SPIR-V] Add Vulkan to target triple (#76749)

Add support for specifying the logical SPIR-V target environment in the
triple as Vulkan. When compiling HLSL, this replaces the DirectX Shader

[HLSL][SPIR-V] Add Vulkan to target triple (#76749)

Add support for specifying the logical SPIR-V target environment in the
triple as Vulkan. When compiling HLSL, this replaces the DirectX Shader
Model with a Vulkan environment instead.

Currently, the only supported combinations of SPIR-V version and Vulkan
environment are:
- Vulkan 1.2 and SPIR-V 1.5
- Vulkan 1.3 and SPIR-V 1.6

Fixes #70051

show more ...

Hurd: Add x86_64 support (#78065)

This adds Hurd toolchain support to Clang's driver in addition to
handling
translating the triple from GCC toolchain-compatible form (x86_64-gnu)
to
the actual

Hurd: Add x86_64 support (#78065)

This adds Hurd toolchain support to Clang's driver in addition to
handling
translating the triple from GCC toolchain-compatible form (x86_64-gnu)
to
the actual triple registered in LLVM (x86_64-pc-hurd-gnu).

show more ...

[llvm] Introduce XROS platform (#77707)

Accepts but otherwise ignores visionOS/XROS target triples as Darwin
based platform.

https://developer.apple.com/documentation/visionos

Triple: Fix handling of macos with unexpected target arches (#75469)

Some tools with a specified target arch, but no full triple default to
the host triple. On macos hosts, this would then force us

Triple: Fix handling of macos with unexpected target arches (#75469)

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.

show more ...

[llvm] Add triple for SerenityOS

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D154395

[Basic] Support 64-bit x86 target for UEFI

Adding support for X86_64 UEFI target to begin with.

Reviewed By: phosek, MaskRay

Differential Revision: https://reviews.llvm.org/D152206

Revert "[Basic] Support 64-bit x86 target for UEFI"

This reverts commit 315a407086b0ab302d0293b720d7f9b3e8f6ffa9.
The new test added fails to link the unit tests correctly and breaks
certain buildbo

Revert "[Basic] Support 64-bit x86 target for UEFI"

This reverts commit 315a407086b0ab302d0293b720d7f9b3e8f6ffa9.
The new test added fails to link the unit tests correctly and breaks
certain buildbots.

show more ...

[Basic] Support 64-bit x86 target for UEFI

Adding support for X86_64 UEFI target to begin with.

Reviewed By: phosek, MaskRay

Differential Revision: https://reviews.llvm.org/D152206

[Driver] Properly report error for unsupported powerpc darwin/macos triples

The removal started at https://reviews.llvm.org/D50989 and
https://reviews.llvm.org/D75494 removed the Triple support. Wit

[Driver] Properly report error for unsupported powerpc darwin/macos triples

The removal started at https://reviews.llvm.org/D50989 and
https://reviews.llvm.org/D75494 removed the Triple support. Without recognizing
Darwin triples as Mach-O, we will get assertion error in ToolChains/Darwin.h due
to the universal binary mechanism.

Fix #47698

---

This requires fixing many misuses of llc -march= and llvm-mc -arch= (
commits 806761a7629df268c8aed49657aeccffa6bca449 and 252c42354eca54274ed7b10c32c73c6937478e8b).

show more ...

Revert "[Driver] Properly report error for unsupported powerpc darwin/macos triples"

This reverts commit 9f77facfce3ca23213c1de2e3e4c969b5187e29d.

The change unintentionally changed lots of codegen

Revert "[Driver] Properly report error for unsupported powerpc darwin/macos triples"

This reverts commit 9f77facfce3ca23213c1de2e3e4c969b5187e29d.

The change unintentionally changed lots of codegen, see
https://github.com/llvm/llvm-project/issues/47698#issuecomment-1714548640

Also revert a follow-up:
This reverts commit b40a5bead2cb95c90ecd8c0fa566722e6133e01c.

show more ...