[TargetParser] Normalize "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu" #140070

MacDue · 2025-05-15T14:50:12Z

This normalizes the "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu", this allows various parts of the LLVM codebase to recognize a GNU environment is present on Amazon Linux. This allows RuntimeLibcalls to mark the sincos* functions as available on Amazon Linux. This allows these functions to be vectorized on Amazon Linux.

…nux-gnu" This normalizes the "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu", this allows various parts of the LLVM codebase to recognize a GNU environment is present on Amazon Linux. This allows RuntimeLibcalls to mark the sincos* functions as available on Amazon Linux. This allows these functions to be vectorized on Amazon Linux.

llvmbot · 2025-05-21T13:12:21Z

@llvm/pr-subscribers-backend-aarch64

@llvm/pr-subscribers-llvm-transforms

Author: Benjamin Maxwell (MacDue)

Changes

This normalizes the "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu", this allows various parts of the LLVM codebase to recognize a GNU environment is present on Amazon Linux. This allows RuntimeLibcalls to mark the sincos* functions as available on Amazon Linux. This allows these functions to be vectorized on Amazon Linux.

Full diff: https://github.com/llvm/llvm-project/pull/140070.diff

5 Files Affected:

(modified) llvm/include/llvm/TargetParser/Triple.h (+2-1)
(modified) llvm/lib/TargetParser/Triple.cpp (+10)
(modified) llvm/test/CodeGen/AArch64/veclib-llvm.sincos.ll (+3)
(modified) llvm/test/Transforms/LoopVectorize/AArch64/multiple-result-intrinsics.ll (+3)
(modified) llvm/unittests/TargetParser/TripleTest.cpp (+8)

diff --git a/llvm/include/llvm/TargetParser/Triple.h b/llvm/include/llvm/TargetParser/Triple.h
index fb6bbc0163701..11d789ae15d8e 100644
--- a/llvm/include/llvm/TargetParser/Triple.h
+++ b/llvm/include/llvm/TargetParser/Triple.h
@@ -194,7 +194,8 @@ class Triple {
     SUSE,
     OpenEmbedded,
     Intel,
-    LastVendorType = Intel
+    Amazon,
+    LastVendorType = Amazon
   };
   enum OSType {
     UnknownOS,
diff --git a/llvm/lib/TargetParser/Triple.cpp b/llvm/lib/TargetParser/Triple.cpp
index e9e6f130f757c..9249e04fe8cdb 100644
--- a/llvm/lib/TargetParser/Triple.cpp
+++ b/llvm/lib/TargetParser/Triple.cpp
@@ -270,6 +270,8 @@ StringRef Triple::getVendorTypeName(VendorType Kind) {
   case PC: return "pc";
   case SCEI: return "scei";
   case SUSE: return "suse";
+  case Amazon:
+    return "amazon";
   }
 
   llvm_unreachable("Invalid VendorType!");
@@ -664,6 +666,7 @@ static Triple::VendorType parseVendor(StringRef VendorName) {
       .Case("suse", Triple::SUSE)
       .Case("oe", Triple::OpenEmbedded)
       .Case("intel", Triple::Intel)
+      .Case("amazon", Triple::Amazon)
       .Default(Triple::UnknownVendor);
 }
 
@@ -1294,6 +1297,13 @@ std::string Triple::normalize(StringRef Str, CanonicalForm Form) {
   if (Vendor == Triple::SUSE && Environment == llvm::Triple::GNUEABI)
     Components[3] = "gnueabihf";
 
+  // Amazon Linux uses a "gnu" environment by default.
+  if (Environment == Triple::UnknownEnvironment && Vendor == Triple::Amazon &&
+      OS == Triple::Linux) {
+    Components.resize(4);
+    Components[3] = "gnu";
+  }
+
   if (OS == Triple::Win32) {
     Components.resize(4);
     Components[2] = "windows";
diff --git a/llvm/test/CodeGen/AArch64/veclib-llvm.sincos.ll b/llvm/test/CodeGen/AArch64/veclib-llvm.sincos.ll
index e18ac46165d2e..7f40efa34271b 100644
--- a/llvm/test/CodeGen/AArch64/veclib-llvm.sincos.ll
+++ b/llvm/test/CodeGen/AArch64/veclib-llvm.sincos.ll
@@ -1,6 +1,9 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --filter "(bl|ptrue)" --version 5
 ; RUN: llc -mtriple=aarch64-gnu-linux -mattr=+neon,+sve -vector-library=sleefgnuabi < %s | FileCheck %s -check-prefix=SLEEF
 ; RUN: llc -mtriple=aarch64-gnu-linux -mattr=+neon,+sve -vector-library=ArmPL < %s | FileCheck %s -check-prefix=ARMPL
+; Check we expand to a vector library call on aarch64-amazon-linux:
+; RUN: llc -mtriple=aarch64-amazon-linux -mattr=+neon,+sve -vector-library=sleefgnuabi < %s | FileCheck %s -check-prefix=SLEEF
+; RUN: llc -mtriple=aarch64-amazon-linux -mattr=+neon,+sve -vector-library=ArmPL < %s | FileCheck %s -check-prefix=ARMPL
 
 define void @test_sincos_v4f32(<4 x float> %x, ptr noalias %out_sin, ptr noalias %out_cos) {
 ; SLEEF-LABEL: test_sincos_v4f32:
diff --git a/llvm/test/Transforms/LoopVectorize/AArch64/multiple-result-intrinsics.ll b/llvm/test/Transforms/LoopVectorize/AArch64/multiple-result-intrinsics.ll
index 544ef5c82c7ac..88590fa443bd9 100644
--- a/llvm/test/Transforms/LoopVectorize/AArch64/multiple-result-intrinsics.ll
+++ b/llvm/test/Transforms/LoopVectorize/AArch64/multiple-result-intrinsics.ll
@@ -1,8 +1,11 @@
 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --filter "(:|sincos|modf|extractvalue|store)" --version 5
 ; RUN: opt -passes=loop-vectorize -mtriple=aarch64-gnu-linux -mcpu=neoverse-v1 -mattr=+sve < %s -S -o - -debug-only=loop-vectorize 2>%t.1 | FileCheck %s --check-prefix=CHECK
 ; RUN: opt -passes=loop-vectorize -mtriple=aarch64-gnu-linux -mcpu=neoverse-v1 -mattr=+sve -vector-library=ArmPL < %s -S -o - -debug-only=loop-vectorize 2>%t.2 | FileCheck %s --check-prefix=CHECK-ARMPL
+; RUN: opt -passes=loop-vectorize -mtriple=aarch64-amazon-linux -mcpu=neoverse-v1 -mattr=+sve -vector-library=ArmPL < %s -S -o - -debug-only=loop-vectorize 2>%t.3 | FileCheck %s --check-prefix=CHECK-ARMPL
 ; RUN: FileCheck --input-file=%t.1 --check-prefix=CHECK-COST %s
 ; RUN: FileCheck --input-file=%t.2 --check-prefix=CHECK-COST-ARMPL %s
+; Check we vectorize the functions with the vector-library on aarch64-amazon-linux:
+; RUN: FileCheck --input-file=%t.3 --check-prefix=CHECK-COST-ARMPL %s
 ; REQUIRES: asserts
 
 ; CHECK-COST-LABEL: sincos_f32
diff --git a/llvm/unittests/TargetParser/TripleTest.cpp b/llvm/unittests/TargetParser/TripleTest.cpp
index 61b3637bb48e2..5850f88b92856 100644
--- a/llvm/unittests/TargetParser/TripleTest.cpp
+++ b/llvm/unittests/TargetParser/TripleTest.cpp
@@ -125,6 +125,11 @@ TEST(TripleTest, ParsedIDs) {
   EXPECT_EQ(Triple::Hurd, T.getOS());
   EXPECT_EQ(Triple::GNU, T.getEnvironment());
 
+  T = Triple("aarch64-amazon-linux");
+  EXPECT_EQ(Triple::aarch64, T.getArch());
+  EXPECT_EQ(Triple::Amazon, T.getVendor());
+  EXPECT_EQ(Triple::Linux, T.getOS());
+
   T = Triple("arm-unknown-linux-android16");
   EXPECT_EQ(Triple::arm, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
@@ -1417,6 +1422,9 @@ TEST(TripleTest, Normalization) {
 
   EXPECT_EQ("x86_64-unknown-linux-gnu", Triple::normalize("x86_64-gnu-linux"));
 
+  EXPECT_EQ("aarch64-amazon-linux-gnu",
+            Triple::normalize("aarch64-amazon-linux"));
+
   EXPECT_EQ("a-unknown-unknown",
             Triple::normalize("a", Triple::CanonicalForm::THREE_IDENT));
   EXPECT_EQ("a-b-unknown",

MaskRay · 2025-05-22T04:16:37Z

Do we need this customization?

Can we say that the user must use --target=aarch64-amazon-linux-gnu instead of --target=aarch64-amazon-linux? When we build LLVM on Amazon Linux, we will need to ensure the auto-detected LLVM_DEFAULT_TARGET_TRIPLE has the -gnu suffix, or require that the user must specify it like some musl-based distributions

MacDue · 2025-05-22T14:46:05Z

Do we need this customization?

Can we say that the user must use --target=aarch64-amazon-linux-gnu instead of --target=aarch64-amazon-linux? When we build LLVM on Amazon Linux, we will need to ensure the auto-detected LLVM_DEFAULT_TARGET_TRIPLE has the -gnu suffix, or require that the user must specify it like some musl-based distributions

I believe that would require some changes in the driver to ensure the clang can still find the GCC installation (due to the issues mentioned in #136114 (comment)).

ozbenh · 2025-06-03T01:42:56Z

Should we be consistent and also add x86_64-amazon-linux-gnu -> x86_64-amazon-linux ?

MacDue · 2025-06-03T09:46:32Z

Should we be consistent and also add x86_64-amazon-linux-gnu -> `x86_64-amazon-linux

Note: This PR does normalizes things the other way around x86_64-amazon-linux -> x86_64-amazon-linux-gnu (knowing Amazon Linux has a GNU environment is needed for some optimizations). The x86 case is already supported (added a test to show that), as this normalization is just looking for Amazon Linux.

MaskRay · 2025-06-03T16:38:54Z

Should we be consistent and also add x86_64-amazon-linux-gnu -> `x86_64-amazon-linux

Note: This PR does normalizes things the other way around x86_64-amazon-linux -> x86_64-amazon-linux-gnu (knowing Amazon Linux has a GNU environment is needed for some optimizations). The x86 case is already supported (added a test to show that), as this normalization is just looking for Amazon Linux.

I think within LLVM, we do should treat x86_64-amazon-linux-gnu as canonical to align with the general rule and other targets.

To pick up the GCC installation, Amazon Linux can install a Clang configuration file to specify --gcc-triple=x86_64-amazon-linux.

pawosm-arm · 2025-06-04T11:41:26Z

Do we need this customization?

In short, yes.

Can we say that the user must use --target=aarch64-amazon-linux-gnu instead of --target=aarch64-amazon-linux? When we build LLVM on Amazon Linux, we will need to ensure the auto-detected LLVM_DEFAULT_TARGET_TRIPLE has the -gnu suffix, or require that the user must specify it like some musl-based distributions

I tired that and I can confirm that this is not the solution. We've been through this several times already, e.g. #136114 (comment)

Should we be consistent and also add x86_64-amazon-linux-gnu -> x86_64-amazon-linux ?

The x86 case is already supported (added a test to show that), as this normalization is just looking for Amazon Linux.

If this can't be resolved for AArch64, then I will raise the necessity for reverting such normalization. We are facing somewhat more serious issue here and to restore LLVM's consistency (and neutrality!) such step may be necessary.

To pick up the GCC installation, Amazon Linux can install a Clang configuration file to specify --gcc-triple=x86_64-amazon-linux.

This will not restore LLVM's consistency (and neutrality!).

pawosm-arm · 2025-06-20T11:46:36Z

Can we reach agreement on this one?

MaskRay · 2025-06-20T16:59:56Z

Do we need this customization?

In short, yes.

Can we say that the user must use --target=aarch64-amazon-linux-gnu instead of --target=aarch64-amazon-linux? When we build LLVM on Amazon Linux, we will need to ensure the auto-detected LLVM_DEFAULT_TARGET_TRIPLE has the -gnu suffix, or require that the user must specify it like some musl-based distributions

I tired that and I can confirm that this is not the solution. We've been through this several times already, e.g. #136114 (comment)

Should we be consistent and also add x86_64-amazon-linux-gnu -> x86_64-amazon-linux ?

The x86 case is already supported (added a test to show that), as this normalization is just looking for Amazon Linux.

If this can't be resolved for AArch64, then I will raise the necessity for reverting such normalization. We are facing somewhat more serious issue here and to restore LLVM's consistency (and neutrality!) such step may be necessary.

To pick up the GCC installation, Amazon Linux can install a Clang configuration file to specify --gcc-triple=x86_64-amazon-linux.

This will not restore LLVM's consistency (and neutrality!).

Sorry for the late response. I've now looked at other changes you've made.

// libcxx/test/std/re/re.alg/re.alg.search/awk.locale.pass.cpp
// XFAIL: target={{.*}}-amazon-linux{{.*}}

Why do we want to use aarch64-amazon-linux instead of aarch64-unknown-linux-gnu? If the only issue is that clang cannot pick up lib/gcc/aarch64-amazon-linux, you can specify a config file for --gcc-triple=aarch64-amazon-linux. In LLVM, we can just use aarch64-unknown-linux-gnu and we don't need to update TargetParser/config.guess at all.

MaskRay

.

pawosm-arm · 2025-06-20T18:20:40Z

Sorry for the late response. I've now looked at other changes you've made.
// libcxx/test/std/re/re.alg/re.alg.search/awk.locale.pass.cpp
// XFAIL: target={{.*}}-amazon-linux{{.*}}
Why do we want to use aarch64-amazon-linux instead of aarch64-unknown-linux-gnu? If the only issue is that clang cannot pick up lib/gcc/aarch64-amazon-linux, you can specify a config file for --gcc-triple=aarch64-amazon-linux. In LLVM, we can just use aarch64-unknown-linux-gnu and we don't need to update TargetParser/config.guess at all.

I can think of many reasons why it is not the best idea. But let's have an example. Some users need to use --no-default-config option. This may be considered an advanced user scenario and if someone is in a need of using such flag, they usually know what they are doing and know about lot of relevant circumstances, e.g. what system they are working with, but then again, it is only an assumption and does not need to be valid - even the most advanced LLVM users may not notice that if they work on Amazon Linux and the CPU is not x86_64, then they need to specify an extra --gcc-triple flag that they might never needed to use on any other system they did the same work in the past. This is very punishing, hence if we demand it for one OS/CPU combination, we should do it for all.

MaskRay · 2025-06-21T03:48:38Z

Sorry for the late response. I've now looked at other changes you've made.
// libcxx/test/std/re/re.alg/re.alg.search/awk.locale.pass.cpp
// XFAIL: target={{.*}}-amazon-linux{{.*}}
Why do we want to use aarch64-amazon-linux instead of aarch64-unknown-linux-gnu? If the only issue is that clang cannot pick up lib/gcc/aarch64-amazon-linux, you can specify a config file for --gcc-triple=aarch64-amazon-linux. In LLVM, we can just use aarch64-unknown-linux-gnu and we don't need to update TargetParser/config.guess at all.
I can think of many reasons why it is not the best idea. But let's have an example. Some users need to use --no-default-config option. This may be considered an advanced user scenario and if someone is in a need of using such flag, they usually know what they are doing and know about lot of relevant circumstances, e.g. what system they are working with, but then again, it is only an assumption and does not need to be valid - even the most advanced LLVM users may not notice that if they work on Amazon Linux and the CPU is not x86_64, then they need to specify an extra --gcc-triple flag that they might never needed to use on any other system they did the same work in the past. This is very punishing, hence if we demand it for one OS/CPU combination, we should do it for all.

We do not support and cannot support automatic GCC selection when using clang --no-default-config.
If --no-default-config is specified, users must also provide the appropriate options to select the desired GCC installation.

You may want to review https://github.com/gentoo/gcc-config/blob/7933c4262ceb0ee44a72880a0f05aa7dc4bbe6f5/gcc-config#L800
It supports multiple GCC versions, allowing users to select the desired version via the gcc-config command. This generates /etc/clang/gentoo-gcc-install.cfg, which Clang reads as part of its default configuration, alongside other customizable options (fortify source, Intel IBT, -z now, etc).

We support the most common triples arch-unknown-linux-gnu and arch-linux-gnu, as well as some vendor specific ones (though their new architectures should migrate to configuration files). We don't want to encourage 100+ Linux distros that customize the "vendor" component to add new elements to Generic_GCC::GCCInstallationDetector::CollectLibDirsAndTriples.

pawosm-arm · 2025-06-21T08:20:27Z

We don't want to encourage 100+ Linux distros that customize the "vendor" component to add new elements to Generic_GCC::GCCInstallationDetector::CollectLibDirsAndTriples.

This is a different situation. We are talking about one particular distribution for which the exception has been already made, yet incompletely, as it covered x86_64 only. I doubt it is in anybody's interest to revert that, but it is also damaging LLVM's architectural neutrality if it cannot cover the other architecture this distribution is available for.

MacDue marked this pull request as ready for review May 21, 2025 13:11

llvmbot added backend:AArch64 llvm:transforms labels May 21, 2025

MacDue requested review from jhuber6, MaskRay and kiranchandramohan May 21, 2025 13:11

MacDue mentioned this pull request May 21, 2025

[TargetParser] Parse Amazon Linux triple and handle RuntimeLibcalls #136114

Open

MacDue requested a review from pawosm-arm May 21, 2025 13:15

X86 test

107430d

MaskRay mentioned this pull request Jun 3, 2025

[Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple #109263

Closed

pawosm-arm approved these changes Jun 20, 2025

View reviewed changes

MaskRay requested changes Jun 20, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[TargetParser] Normalize "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu" #140070

[TargetParser] Normalize "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu" #140070

Uh oh!

MacDue commented May 15, 2025

Uh oh!

llvmbot commented May 21, 2025 •

edited

Loading

Uh oh!

MaskRay commented May 22, 2025 •

edited

Loading

Uh oh!

MacDue commented May 22, 2025

Uh oh!

ozbenh commented Jun 3, 2025

Uh oh!

MacDue commented Jun 3, 2025 •

edited

Loading

Uh oh!

MaskRay commented Jun 3, 2025

Uh oh!

pawosm-arm commented Jun 4, 2025 •

edited

Loading

Uh oh!

pawosm-arm commented Jun 20, 2025

Uh oh!

MaskRay commented Jun 20, 2025 •

edited

Loading

Uh oh!

MaskRay left a comment

Uh oh!

pawosm-arm commented Jun 20, 2025

Uh oh!

MaskRay commented Jun 21, 2025

Uh oh!

pawosm-arm commented Jun 21, 2025

Uh oh!

Uh oh!

[TargetParser] Normalize "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu" #140070

Are you sure you want to change the base?

[TargetParser] Normalize "aarch64-amazon-linux" to "aarch64-amazon-linux-gnu" #140070

Uh oh!

Conversation

MacDue commented May 15, 2025

Uh oh!

llvmbot commented May 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaskRay commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MacDue commented May 22, 2025

Uh oh!

ozbenh commented Jun 3, 2025

Uh oh!

MacDue commented Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaskRay commented Jun 3, 2025

Uh oh!

pawosm-arm commented Jun 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pawosm-arm commented Jun 20, 2025

Uh oh!

MaskRay commented Jun 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaskRay left a comment

Choose a reason for hiding this comment

Uh oh!

pawosm-arm commented Jun 20, 2025

Uh oh!

MaskRay commented Jun 21, 2025

Uh oh!

pawosm-arm commented Jun 21, 2025

Uh oh!

Uh oh!

llvmbot commented May 21, 2025 •

edited

Loading

MaskRay commented May 22, 2025 •

edited

Loading

MacDue commented Jun 3, 2025 •

edited

Loading

pawosm-arm commented Jun 4, 2025 •

edited

Loading

MaskRay commented Jun 20, 2025 •

edited

Loading