[clang] [llvm] [LLVM][AArch64] Add ASM constraints for reduced GPR register ranges. (PR #70970)
peterwaller-arm wrote: Worth a simultaneous update to the langref? https://github.com/llvm/llvm-project/blob/e2564b27472638d2e2019e6cd2fc6d6d608f8b8c/llvm/docs/LangRef.rst#L5080-L5106 https://github.com/llvm/llvm-project/pull/70970 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [LLVM][AArch64] Add ASM constraints for reduced GPR register ranges. (PR #70970)
https://github.com/peterwaller-arm approved this pull request. https://github.com/llvm/llvm-project/pull/70970 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 2db2a4e - [doc][ReleaseNotes] Document AArch64 SVE ABI fix from D127209
Author: Peter Waller Date: 2022-07-07T10:55:40Z New Revision: 2db2a4e112406e97bad82b8e78492a472c13588e URL: https://github.com/llvm/llvm-project/commit/2db2a4e112406e97bad82b8e78492a472c13588e DIFF: https://github.com/llvm/llvm-project/commit/2db2a4e112406e97bad82b8e78492a472c13588e.diff LOG: [doc][ReleaseNotes] Document AArch64 SVE ABI fix from D127209 D127209 fixed LLVM to bring it in line with the AAPCS. The fix affects functions where the first SVE parameter appears in the 9th or later arguments, and the function does not return an SVE type. Differential Revision: https://reviews.llvm.org/D129135 Added: Modified: clang/docs/ReleaseNotes.rst Removed: diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst index 0f542e08b841c..93d4ed58d4de5 100644 --- a/clang/docs/ReleaseNotes.rst +++ b/clang/docs/ReleaseNotes.rst @@ -503,6 +503,14 @@ ABI Changes in Clang (e.g. ``int : 0``) no longer prevents the structure from being considered a homogeneous floating-point or vector aggregate. The new behavior agrees with the AAPCS specification, and matches the similar bug fix in GCC 12.1. +- Targeting AArch64, since D127209 LLVM now only preserves the z8-z23 + and p4-p15 registers across a call if the registers z0-z7 or p0-p3 are + used to pass data into or out of a subroutine. The new behavior + matches the AAPCS. Previously LLVM preserved z8-z23 and p4-p15 across + a call if the callee had an SVE type anywhere in its signature. This + would cause an incorrect use of the caller-preserved z8-z23 and p4-p15 + ABI for example if the 9th argument or greater were the first SVE type + in the signature of a function. - All copy constructors can now be trivial if they are not user-provided, regardless of the type qualifiers of the argument of the defaulted constructor, fixing dr2171. ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[compiler-rt] [llvm] [flang] [clang] [clang-tools-extra] [AArch64][compiler-rt] Avoid use of libc header in sme-libc-routines (PR #79454)
https://github.com/peterwaller-arm updated https://github.com/llvm/llvm-project/pull/79454 >From 18fbfe3d757372fc904146a9156e8af466c9f013 Mon Sep 17 00:00:00 2001 From: Peter Waller Date: Thu, 25 Jan 2024 14:29:45 + Subject: [PATCH] [AArch64][compiler-rt] Avoid use of libc header in sme-libc-routines The use of `#include ` introduces a libc dependency. In many build environments such a file can be found under e.g. /usr/include, but this does not correspond to the libc in use, which may not be available until after the builtins have been built. So far as I understand, it's not valid to have a dependency on libc from builtins; there are a handful of such includes in builtins, but they are protected by ifdefs. Instead, use which is provided by the compiler's resource headers and so should always be available. --- compiler-rt/lib/builtins/aarch64/sme-libc-routines.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/compiler-rt/lib/builtins/aarch64/sme-libc-routines.c b/compiler-rt/lib/builtins/aarch64/sme-libc-routines.c index cd73025a19cc1ac..89b52b0d1a8805c 100644 --- a/compiler-rt/lib/builtins/aarch64/sme-libc-routines.c +++ b/compiler-rt/lib/builtins/aarch64/sme-libc-routines.c @@ -1,4 +1,4 @@ -#include +#include // WARNING: When building the scalar versions of these functions you need to // use the compiler flag "-mllvm -disable-loop-idiom-all" to prevent clang ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang-tools-extra] [compiler-rt] [flang] [AArch64][compiler-rt] Avoid use of libc header in sme-libc-routines (PR #79454)
https://github.com/peterwaller-arm closed https://github.com/llvm/llvm-project/pull/79454 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 2315e98 - [AArch64][Driver][SVE] Push missing SVE feature error from driver to frontend
Author: Peter Waller
Date: 2020-12-10T12:43:14Z
New Revision: 2315e9874c92bf625ec84a5f45a4fa28bfbc16ce
URL:
https://github.com/llvm/llvm-project/commit/2315e9874c92bf625ec84a5f45a4fa28bfbc16ce
DIFF:
https://github.com/llvm/llvm-project/commit/2315e9874c92bf625ec84a5f45a4fa28bfbc16ce.diff
LOG: [AArch64][Driver][SVE] Push missing SVE feature error from driver to
frontend
... and give more guidance to users.
If specifying -msve-vector-bits on a non-SVE target, clang would say:
error: '-msve-vector-bits' is not supported without SVE enabled
1. The driver lacks logic for "implied features".
This would result in this error being raised for -march=...+sve2,
even though +sve2 implies +sve.
2. Feature implication is well modelled in LLVM, so push the error down
the stack.
3. Hint to the user what flag they need to consider setting.
Now clang fails later, when the feature is used, saying:
aarch64-sve-vector-bits.c:42:41: error: 'arm_sve_vector_bits' attribute is
not supported on targets missing 'sve'; specify an appropriate -march= or -mcpu=
typedef svint32_t noflag __attribute__((arm_sve_vector_bits(256)));
Move clang/test/Sema/{neon => arm}-vector-types-support.c and put tests for
this warning together in one place.
Reviewed By: sdesmalen
Differential Revision: https://reviews.llvm.org/D92487
Added:
clang/test/Sema/arm-vector-types-support.c
Modified:
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/lib/Sema/SemaType.cpp
clang/test/Driver/aarch64-sve-vector-bits.c
Removed:
clang/test/Sema/neon-vector-types-support.c
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 8ca176d3bb43..0e85be8f058b 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -534,9 +534,6 @@ def err_drv_cannot_mix_options : Error<"cannot specify '%1'
along with '%0'">;
def err_drv_invalid_object_mode : Error<"OBJECT_MODE setting %0 is not
recognized and is not a valid setting.">;
-def err_drv_invalid_sve_vector_bits : Error<
- "'-msve-vector-bits' is not supported without SVE enabled">;
-
def err_aix_default_altivec_abi : Error<
"The default Altivec ABI on AIX is not yet supported, use '-mabi=vec-extabi'
for the extended Altivec ABI">;
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 97773d35a694..363bcc1d383d 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2843,7 +2843,8 @@ def warn_unsupported_target_attribute
"attribute ignored">,
InGroup;
def err_attribute_unsupported
-: Error<"%0 attribute is not supported for this target">;
+: Error<"%0 attribute is not supported on targets missing %1;"
+" specify an appropriate -march= or -mcpu=">;
// The err_*_attribute_argument_not_int are separate because they're used by
// VerifyIntegerConstantExpression.
def err_aligned_attribute_argument_not_int : Error<
diff --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index 0fc531b8c3a0..fca6d95d361b 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -381,12 +381,6 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
if (V8_6Pos != std::end(Features))
V8_6Pos = Features.insert(std::next(V8_6Pos), {"+i8mm", "+bf16"});
- bool HasSve = llvm::is_contained(Features, "+sve");
- // -msve-vector-bits= flag is valid only if SVE is enabled.
- if (Args.hasArg(options::OPT_msve_vector_bits_EQ))
-if (!HasSve)
- D.Diag(diag::err_drv_invalid_sve_vector_bits);
-
if (Arg *A = Args.getLastArg(options::OPT_mno_unaligned_access,
options::OPT_munaligned_access)) {
if (A->getOption().matches(options::OPT_mno_unaligned_access))
diff --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index fbdbfbc9f8ec..6485bebc0e8e 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -7799,7 +7799,8 @@ static void HandleNeonVectorTypeAttr(QualType &CurType,
const ParsedAttr &Attr,
// not to need a separate attribute)
if (!S.Context.getTargetInfo().hasFeature("neon") &&
!S.Context.getTargetInfo().hasFeature("mve")) {
-S.Diag(Attr.getLoc(), diag::err_attribute_unsupported) << Attr;
+S.Diag(Attr.getLoc(), diag::err_attribute_unsupported)
+<< Attr << "'neon' or 'mve'";
Attr.setInvalid();
return;
}
@@ -7842,7 +7843,7 @@ static void HandleArmSveVectorBitsTypeAttr(QualType
&CurType, ParsedAttr &Attr,
Sem
[clang] 2d574a1 - [CodeGen][AArch64][SVE] Canonicalize intrinsic rdffr{ => _z}
Author: Peter Waller
Date: 2021-05-20T16:22:50Z
New Revision: 2d574a110440597eefe1b2a8b6144e4e89c21d05
URL:
https://github.com/llvm/llvm-project/commit/2d574a110440597eefe1b2a8b6144e4e89c21d05
DIFF:
https://github.com/llvm/llvm-project/commit/2d574a110440597eefe1b2a8b6144e4e89c21d05.diff
LOG: [CodeGen][AArch64][SVE] Canonicalize intrinsic rdffr{ => _z}
Follow up to D101357 / 3fa6510f6.
Supersedes D102330.
Goal: Use flags setting rdffrs instead of rdffr + ptest.
Problem: RDFFR_P doesn't have have a flags setting equivalent.
Solution: in instcombine, canonicalize to RDFFR_PP at the IR level, and
rely on RDFFR_PP+PTEST => RDFFRS_PP optimization in
AArch64InstrInfo::optimizePTestInstr.
While here:
* Test that rdffr.z+ptest generates a rdffrs.
* Use update_{test,llc}_checks.py on the tests.
* Use sve attribute on functions.
Differential Revision: https://reviews.llvm.org/D102623
Added:
llvm/test/Transforms/InstCombine/AArch64/sve-intrinsics-rdffr-predication.ll
Modified:
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_rdffr.c
llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
llvm/test/CodeGen/AArch64/sve-intrinsics-ffr-manipulation.ll
Removed:
diff --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_rdffr.c
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_rdffr.c
index 9b871ee3a8dc..a85ac7bb5cef 100644
--- a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_rdffr.c
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_rdffr.c
@@ -7,7 +7,8 @@
svbool_t test_svrdffr()
{
// CHECK-LABEL: test_svrdffr
- // CHECK: %[[INTRINSIC:.*]] = call
@llvm.aarch64.sve.rdffr()
+ // CHECK: %[[INTRINSIC:.*]] = call
@llvm.aarch64.sve.rdffr.z(
+ // CHECK-NOT: rdffr
// CHECK: ret %[[INTRINSIC]]
return svrdffr();
}
diff --git a/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
b/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
index 90762052dc3a..846c07863467 100644
--- a/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
+++ b/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
@@ -470,6 +470,23 @@ static Optional
instCombineSVELast(InstCombiner &IC,
return IC.replaceInstUsesWith(II, Extract);
}
+static Optional instCombineRDFFR(InstCombiner &IC,
+IntrinsicInst &II) {
+ LLVMContext &Ctx = II.getContext();
+ IRBuilder<> Builder(Ctx);
+ Builder.SetInsertPoint(&II);
+ // Replace rdffr with predicated rdffr.z intrinsic, so that
optimizePTestInstr
+ // can work with RDFFR_PP for ptest elimination.
+ auto *AllPat =
+ ConstantInt::get(Type::getInt32Ty(Ctx), AArch64SVEPredPattern::all);
+ auto *PTrue = Builder.CreateIntrinsic(Intrinsic::aarch64_sve_ptrue,
+{II.getType()}, {AllPat});
+ auto *RDFFR =
+ Builder.CreateIntrinsic(Intrinsic::aarch64_sve_rdffr_z, {}, {PTrue});
+ RDFFR->takeName(&II);
+ return IC.replaceInstUsesWith(II, RDFFR);
+}
+
Optional
AArch64TTIImpl::instCombineIntrinsic(InstCombiner &IC,
IntrinsicInst &II) const {
@@ -481,6 +498,8 @@ AArch64TTIImpl::instCombineIntrinsic(InstCombiner &IC,
return instCombineConvertFromSVBool(IC, II);
case Intrinsic::aarch64_sve_dup:
return instCombineSVEDup(IC, II);
+ case Intrinsic::aarch64_sve_rdffr:
+return instCombineRDFFR(IC, II);
case Intrinsic::aarch64_sve_lasta:
case Intrinsic::aarch64_sve_lastb:
return instCombineSVELast(IC, II);
diff --git a/llvm/test/CodeGen/AArch64/sve-intrinsics-ffr-manipulation.ll
b/llvm/test/CodeGen/AArch64/sve-intrinsics-ffr-manipulation.ll
index 7460037078d1..bc07c972e5fb 100644
--- a/llvm/test/CodeGen/AArch64/sve-intrinsics-ffr-manipulation.ll
+++ b/llvm/test/CodeGen/AArch64/sve-intrinsics-ffr-manipulation.ll
@@ -1,33 +1,51 @@
-; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s | FileCheck %s
+
+target triple = "aarch64-unknown-linux-gnu"
;
; RDFFR
;
-define @rdffr() {
+define @rdffr() #0 {
; CHECK-LABEL: rdffr:
-; CHECK: rdffr p0.b
-; CHECK-NEXT: ret
+; CHECK: // %bb.0:
+; CHECK-NEXT:rdffr p0.b
+; CHECK-NEXT:ret
%out = call @llvm.aarch64.sve.rdffr()
ret %out
}
-define @rdffr_z( %pg) {
+define @rdffr_z( %pg) #0 {
; CHECK-LABEL: rdffr_z:
-; CHECK: rdffr p0.b, p0/z
-; CHECK-NEXT: ret
+; CHECK: // %bb.0:
+; CHECK-NEXT:rdffr p0.b, p0/z
+; CHECK-NEXT:ret
%out = call @llvm.aarch64.sve.rdffr.z(
%pg)
ret %out
}
+; Test that rdffr.z followed by ptest optimizes to flags-setting rdffrs.
+define i1 @rdffr_z_ptest( %pg) #0 {
+; CHECK-LABEL: rdffr_z_ptest:
+; CHECK: // %bb.0:
+; CHECK-NEXT:rdffrs p0.b, p0/z
+; CHECK-NEXT:cset w0, ne
+; CHECK-NEXT:ret
+ %rdffr = call @llvm.aarch64.sve.rdffr.z( %pg)
+ %out = call
[clang] 8cb9e3c - [AArch64] Install arm_neon_sve_bridge.h
Author: Peter Waller
Date: 2022-11-03T07:55:57Z
New Revision: 8cb9e3c3ce1e7e1658921f90420b68ca16bb98fc
URL:
https://github.com/llvm/llvm-project/commit/8cb9e3c3ce1e7e1658921f90420b68ca16bb98fc
DIFF:
https://github.com/llvm/llvm-project/commit/8cb9e3c3ce1e7e1658921f90420b68ca16bb98fc.diff
LOG: [AArch64] Install arm_neon_sve_bridge.h
arm_neon_sve_bridge.h is not generated, so the rules which ensure the
generated files get copied into the installation prefix don't apply to
this one.
Add it to the aarch64_only_files set instead, which ensures it ends up
both in the build directory and the installation directory.
Tested with build targets `clang-resource-headers` and
`install-clang-resource-headers`.
Differential Revision: https://reviews.llvm.org/D137239
Added:
Modified:
clang/lib/Headers/CMakeLists.txt
Removed:
diff --git a/clang/lib/Headers/CMakeLists.txt
b/clang/lib/Headers/CMakeLists.txt
index f69bf14891440..402b7374ca816 100644
--- a/clang/lib/Headers/CMakeLists.txt
+++ b/clang/lib/Headers/CMakeLists.txt
@@ -33,6 +33,7 @@ set(arm_only_files
set(aarch64_only_files
arm64intr.h
+ arm_neon_sve_bridge.h
)
set(cuda_files
@@ -326,10 +327,6 @@ if(ARM IN_LIST LLVM_TARGETS_TO_BUILD OR AArch64 IN_LIST
LLVM_TARGETS_TO_BUILD)
clang_generate_header(-gen-arm-mve-header arm_mve.td arm_mve.h)
# Generate arm_cde.h
clang_generate_header(-gen-arm-cde-header arm_cde.td arm_cde.h)
- # Copy arm_neon_sve_bridge.h
- copy_header_to_output_dir(${CMAKE_CURRENT_SOURCE_DIR}
-arm_neon_sve_bridge.h
- )
# Add headers to target specific lists
list(APPEND arm_common_generated_files
@@ -345,7 +342,6 @@ if(ARM IN_LIST LLVM_TARGETS_TO_BUILD OR AArch64 IN_LIST
LLVM_TARGETS_TO_BUILD)
list(APPEND aarch64_only_generated_files
"${CMAKE_CURRENT_BINARY_DIR}/arm_sve.h"
"${CMAKE_CURRENT_BINARY_DIR}/arm_bf16.h"
-"${output_dir}/arm_neon_sve_bridge.h"
)
endif()
if(RISCV IN_LIST LLVM_TARGETS_TO_BUILD)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 6bf5580 - [clang][driver] Add basic --driver-mode=flang support for fortran
Author: Peter Waller
Date: 2019-10-30T10:42:22Z
New Revision: 6bf55804924d5a1d902925ad080b1a2b57c5c75c
URL:
https://github.com/llvm/llvm-project/commit/6bf55804924d5a1d902925ad080b1a2b57c5c75c
DIFF:
https://github.com/llvm/llvm-project/commit/6bf55804924d5a1d902925ad080b1a2b57c5c75c.diff
LOG: [clang][driver] Add basic --driver-mode=flang support for fortran
This patch adds a new Flang mode. When in Flang mode, the driver will
invoke flang for fortran inputs instead of falling back to the GCC
toolchain as it would otherwise do.
The behaviour of other driver modes are left unmodified to preserve
backwards compatibility.
It is intended that a soon to be implemented binary in the flang project
will import libclangDriver and run the clang driver in the new flang
mode.
Please note that since the binary invoked by the driver is under
development, there will no doubt be further tweaks necessary in future
commits.
* Initial support is added for basic driver phases
* -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified)
* -### tests are added for all of the above
* This is more than is supported by f18 so far, which will emit errors
for those options which are unimplemented.
* A test is added that ensures that clang gives a reasonable error
message if flang is not available in the path (without -###).
* Test that the driver accepts multiple inputs in --driver-mode=flang.
* Test that a combination of C and Fortran inputs run both clang and
flang in --driver-mode=flang.
* clang/test/Driver/fortran.f95 is fixed to use the correct fortran
comment character.
Differential revision: https://reviews.llvm.org/D63607
Added:
clang/lib/Driver/ToolChains/Flang.cpp
clang/lib/Driver/ToolChains/Flang.h
clang/test/Driver/flang/Inputs/one.f90
clang/test/Driver/flang/Inputs/other.c
clang/test/Driver/flang/Inputs/two.f90
clang/test/Driver/flang/flang.F90
clang/test/Driver/flang/flang.f90
clang/test/Driver/flang/multiple-inputs-mixed.f90
clang/test/Driver/flang/multiple-inputs.f90
Modified:
clang/include/clang/Driver/Driver.h
clang/include/clang/Driver/ToolChain.h
clang/include/clang/Driver/Types.h
clang/lib/Driver/CMakeLists.txt
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/Types.cpp
clang/test/Driver/fortran.f95
clang/test/Driver/lit.local.cfg
Removed:
diff --git a/clang/include/clang/Driver/Driver.h
b/clang/include/clang/Driver/Driver.h
index 5e7283e31ee0..64f1eb8cb5d7 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -65,7 +65,8 @@ class Driver {
GCCMode,
GXXMode,
CPPMode,
-CLMode
+CLMode,
+FlangMode
} Mode;
enum SaveTempsMode {
@@ -180,6 +181,10 @@ class Driver {
/// Whether the driver should follow cl.exe like behavior.
bool IsCLMode() const { return Mode == CLMode; }
+ /// Whether the driver should invoke flang for fortran inputs.
+ /// Other modes fall back to calling gcc which in turn calls gfortran.
+ bool IsFlangMode() const { return Mode == FlangMode; }
+
/// Only print tool bindings, don't build any jobs.
unsigned CCCPrintBindings : 1;
@@ -534,6 +539,10 @@ class Driver {
/// handle this action.
bool ShouldUseClangCompiler(const JobAction &JA) const;
+ /// ShouldUseFlangCompiler - Should the flang compiler be used to
+ /// handle this action.
+ bool ShouldUseFlangCompiler(const JobAction &JA) const;
+
/// Returns true if we are performing any kind of LTO.
bool isUsingLTO() const { return LTOMode != LTOK_None; }
diff --git a/clang/include/clang/Driver/ToolChain.h
b/clang/include/clang/Driver/ToolChain.h
index c40af1e6e01f..26d8d43dd2fc 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -134,6 +134,7 @@ class ToolChain {
path_list ProgramPaths;
mutable std::unique_ptr Clang;
+ mutable std::unique_ptr Flang;
mutable std::unique_ptr Assemble;
mutable std::unique_ptr Link;
mutable std::unique_ptr IfsMerge;
@@ -141,6 +142,7 @@ class ToolChain {
mutable std::unique_ptr OffloadWrapper;
Tool *getClang() const;
+ Tool *getFlang() const;
Tool *getAssemble() const;
Tool *getLink() const;
Tool *getIfsMerge() const;
diff --git a/clang/include/clang/Driver/Types.h
b/clang/include/clang/Driver/Types.h
index a605450e6e3d..c7c38fa52593 100644
--- a/clang/include/clang/Driver/Types.h
+++ b/clang/include/clang/Driver/Types.h
@@ -84,6 +84,9 @@ namespace types {
/// isObjC - Is this an "ObjC" input (Obj-C and Obj-C++ sources and headers).
bool isObjC(ID Id);
+ /// isFortran - Is this a Fortran input.
+ bool isFortran(ID Id);
+
/// isSrcFile - Is this a source file, i.e. something that still has to be
/// preprocessed. The logic behind this is the same that decides if the first
/// compi
[clang] c75cd3c - [clang][driver][flang] Mark test as unsupported on darwin
Author: Peter Waller Date: 2019-10-30T17:01:59Z New Revision: c75cd3c7f0f924d53f07a9cce60c362751678e0c URL: https://github.com/llvm/llvm-project/commit/c75cd3c7f0f924d53f07a9cce60c362751678e0c DIFF: https://github.com/llvm/llvm-project/commit/c75cd3c7f0f924d53f07a9cce60c362751678e0c.diff LOG: [clang][driver][flang] Mark test as unsupported on darwin D63607 made mac builders unhappy by failing this test, and it isn't yet obvious why. Mark as unsupported as a temporary measure. Signed-off-by: Peter Waller Added: Modified: clang/test/Driver/flang/flang.f90 Removed: diff --git a/clang/test/Driver/flang/flang.f90 b/clang/test/Driver/flang/flang.f90 index 9d47c7c90225..97e4847f8439 100644 --- a/clang/test/Driver/flang/flang.f90 +++ b/clang/test/Driver/flang/flang.f90 @@ -1,3 +1,7 @@ +! D63607 made mac builders unhappy by failing this test, and it isn't +! yet obvious why. Mark as unsupported as a temporary measure. +! UNSUPPORTED: darwin + ! Check that flang -fc1 is invoked when in --driver-mode=flang. ! This is a copy of flang_ucase.F90 because the driver has logic in it which ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)
peterwaller-arm wrote: > @peterwaller-arm I noticed that in > `llvm/test/CodeGen/AArch64/combine_andor_with_cmps.ll`, `FMAXNUM_IEEE` is > claimed that it is not supported. While I noticed that `fmaxnm` follows the > rules of `maxNUM` of IEEE754-2008. Is there any other limitation of `fmaxnm`? This is not an area I know a great deal about and I'm about to go on leave, so I'm probably not the best person to ask. Perhaps the author of the comment (on https://reviews.llvm.org/D159240) @kmitropoulou can help? Could the comment mean that it's not currently supported by LLVM rather than not supported by the ISA? I see that the details of how NaNs are handled matters. I'm afraid I don't have time to get to the bottom of this currently. https://github.com/llvm/llvm-project/pull/93841 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [lld] [llvm] Triple::normalize: Set OS for 3-component triple with none as middle (PR #89638)
peterwaller-arm wrote: I have tested building a toolchain using `aarch64-none-elf`, and the problems described in my comment on https://github.com/llvm/llvm-project/pull/89234#issuecomment-2069019606 are resolved. The only change I had to make was to update some references to `aarch64-none-elf` to reference `aarch64-unknown-none-elf`, reflecting the change in compiler-rt install paths introduced in #89234. I concur with Sander that it seems prudent to have the functional change in its own commit, in case it requires further revert flip-flop. https://github.com/llvm/llvm-project/pull/89638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [lld] [llvm] Triple::normalize: Set OS for 3-component triple with none as middle (PR #89638)
peterwaller-arm wrote: I've just posted an RFC to discourse about how to handle triple normalization: https://discourse.llvm.org/t/rfc-baremetal-target-triple-normalization/78524 https://github.com/llvm/llvm-project/pull/89638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [llvm] Triple::normalize: Use none as OS for XX-none-ABI (PR #89638)
peterwaller-arm wrote: Thanks @wzssyqa again for implementing this and splitting bits out per Sander's suggestion. I propose we merge these changes tomorrow, on the understanding that each of the two patches (this and #90313) are passing tests. It looks to me like you're working towards that goal. What I see in CI for this PR is `LLVM-Unit :: TargetParser/./TargetParserTests/TripleTest/Normalization` is currently failing. Is it possible to have two patches such that they're both green? My expectation is that the majority of the triple changes in the source are unrelated to normalization and would work the same before and after the functional changes to triple normalization. (And that those tests which are impacted by changes to triple normalization should of course change in the same commit to keep things green). https://github.com/llvm/llvm-project/pull/89638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [llvm] Triple::normalize: Use none as OS for XX-none-ABI (PR #89638)
@@ -217,7 +217,7 @@ function test-armv7m-picolibc() {
"${@}"
${NINJA} -vC "${BUILD_DIR}/compiler-rt" install
-mv "${BUILD_DIR}/install/lib/armv7m-none-unknown-eabi"/*
"${BUILD_DIR}/install/lib"
+mv "${BUILD_DIR}/install/lib/armv7m-unknown-none-eabi"/*
"${BUILD_DIR}/install/lib"
peterwaller-arm wrote:
This triple is 'used' by the version of the clang on the builder. Please remove
this update, I'm in touch with @DavidSpickett who will make sure it gets
updated at the right time.
https://github.com/llvm/llvm-project/pull/89638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [llvm] Triple::normalize: Use none as OS for XX-none-ABI (PR #89638)
https://github.com/peterwaller-arm requested changes to this pull request. Thanks for doing this and waiting for RFC comments. I think this can be merged, the one thing which needs fixing is removing the change I've commented on so that the picolibc builder can succeed (it uses a version of clang on the builder, which @DavidSpickett will update at the right time). https://github.com/llvm/llvm-project/pull/89638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [libcxx] [llvm] Triple::normalize: Use none as OS for XX-none-ABI (PR #89638)
https://github.com/peterwaller-arm edited https://github.com/llvm/llvm-project/pull/89638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Triple::normalize: Use none as OS for XX-none-ABI (PR #89638)
https://github.com/peterwaller-arm approved this pull request. LGTM, thanks for supplying a quick fix and iterating this, and thanks for waiting for input on the RFC. https://github.com/llvm/llvm-project/pull/89638 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][Docs] Add release note for {target}-none-{environment} triple normalization changes (PR #90734)
https://github.com/peterwaller-arm approved this pull request. https://github.com/llvm/llvm-project/pull/90734 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
peterwaller-arm wrote: OK, Thanks for the input all. I'm abandoning this change, I'm not following up for the time being if someone is able to fix this. Part of the problem is that it's not clear what a clean/correct cmake check would be to determine the triple. My current thinking is that cmake could take the existing inferred triple from config.guess and then amend the vendor. What's unclear is how to determine the vendor in an accurate and scalable way, without making a mess. Perhaps it would be even better if someone can fix config.guess since that is used by other projects, and then LLVM would not need special logic and it keeps the detection logic in one place. https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
https://github.com/peterwaller-arm closed https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
peterwaller-arm wrote: >So what should we (Amazon Linux) do to help with this ? What I think is needed is: * Public consensus on how to detect the triple (or at least the vendor) on Amazon Linux. This would help coming from you. * Consensus on how/when to insert the triple into `LLVM_INFERRED_HOST_TRIPLE`. > `LLVM_DEFAULT_TARGET_TRIPLE` if unspecified comes from > `LLVM_INFERRED_HOST_TRIPLE` which comes from config.guess in here: > https://github.com/llvm/llvm-project/blob/592adb0b24aca2ccc88d9f5f1c427361897d1172/llvm/cmake/modules/GetHostTriple.cmake#L49 I don't know enough about the history of the current GetHostTriple and the fact it calls into the (long) GNU-licensed vendored config.guess file. My guess is that a solution should continue to use the existing config.guess; but that would need to be fixed by someone else in https://git.savannah.gnu.org/cgit/config.git/ and then the vendored copy updating. It seems to me this is the cleanest minimal solution (which will also fix other things), but it assumes config.guess is here to stay in the LLVM repository. If not, then an alternative method would be to add logic to GetHostTriple cmake file linked above to determine the triple without use of config.guess [0]. There is also the possibility of a hybrid solution of patching the triple coming out of config.guess to insert the vendor but that would seem to be adding to the mess, so I assume that's a non-starter. [0] I'm not sure how; maybe it's as simple as checking for or enumerating some paths, but I'm not sure we ideally want to be 'in the limit' adding many path checks during configure time either. If only there existed a `/etc/triple` that could be read. https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
peterwaller-arm wrote: @MaskRay please would you kindly reconsider aarch64-amazon-linux triple as an exception given the presence of x86_64 equivalent? I've explored that `LLVM_DEFAULT_TARGET_TRIPLE` if unspecified comes from `LLVM_INFERRED_HOST_TRIPLE` which comes from config.guess in here: https://github.com/llvm/llvm-project/blob/592adb0b24aca2ccc88d9f5f1c427361897d1172/llvm/cmake/modules/GetHostTriple.cmake#L49 config.guess is copy of an external project with a different license; this is what reports `aarch64-unknown-linux-gnu`. For the time being it would seem fair to put aarch64 on the same footing as x86_64 here. https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
https://github.com/peterwaller-arm ready_for_review https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
peterwaller-arm wrote: I've checked the buildkite failures are in cfi-standalone-lld-thinlto-x86_64, which I believe are unrelated to this change. https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
https://github.com/peterwaller-arm created
https://github.com/llvm/llvm-project/pull/109263
I note that the comment nearby says "They are not needed when the user has
correct LLVM_DEFAULT_TARGET_TRIPLE" and "The lists should shrink over time".
The behviour was diverged between X86 and aarch64: prior to this patch,
a standard clang with no configuration works on x86 but not aarch64
amazon linux; the latter fails to find C++ headers and libraries.
>From 3d11c72fd4f2c761b736dd760cc630eb21f06ea8 Mon Sep 17 00:00:00 2001
From: Peter Waller
Date: Thu, 19 Sep 2024 08:41:10 +0100
Subject: [PATCH] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux
triple
I note that the comment nearby says "They are not needed when the user has
correct LLVM_DEFAULT_TARGET_TRIPLE" and "The lists should shrink over time".
The behviour was diverged between X86 and aarch64: prior to this patch,
a standard clang with no configuration works on x86 but not aarch64
amazon linux; the latter fails to find C++ headers and libraries.
---
clang/lib/Driver/ToolChains/Gnu.cpp | 3 +-
.../lib/gcc/aarch64-amazon-linux/7/crtbegin.o | 0
.../gcc/aarch64-amazon-linux/7/crtbeginT.o| 0
.../lib/gcc/aarch64-amazon-linux/7/crtend.o | 0
clang/test/Driver/linux-ld.c | 45 +--
5 files changed, 33 insertions(+), 15 deletions(-)
create mode 100644
clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtbeginT.o
create mode 100644
clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtend.o
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 603d0468dd3f3c..f075ed0b35b6c5 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2470,7 +2470,8 @@ void
Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
// lists should shrink over time. Please don't add more elements to *Triples.
static const char *const AArch64LibDirs[] = {"/lib64", "/lib"};
static const char *const AArch64Triples[] = {
- "aarch64-none-linux-gnu", "aarch64-redhat-linux", "aarch64-suse-linux"};
+ "aarch64-none-linux-gnu", "aarch64-redhat-linux", "aarch64-suse-linux",
+ "aarch64-amazon-linux"};
static const char *const AArch64beLibDirs[] = {"/lib"};
static const char *const AArch64beTriples[] = {"aarch64_be-none-linux-gnu"};
diff --git
a/clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtbegin.o
b/clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtbegin.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtbeginT.o
b/clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtbeginT.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtend.o
b/clang/test/Driver/Inputs/ami_linux_tree/usr/lib/gcc/aarch64-amazon-linux/7/crtend.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 28fb075a80dbbc..3f775cc7b1003b 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -1705,23 +1705,40 @@
// CHECK-LD-RHEL7-DTS-NOT: /usr/bin/ld
// CHECK-LD-RHEL7-DTS:
[[SYSROOT]]/usr/lib/gcc/x86_64-redhat-linux/7/../../../../bin/ld
-// Check whether gcc7 install works fine on Amazon Linux AMI
+// Check whether gcc7 install works fine on Amazon Linux AMI targeting x86_64
// RUN: %clang -### %s -Werror -no-pie 2>&1 \
// RUN: --target=x86_64-amazon-linux -rtlib=libgcc --unwindlib=platform \
// RUN: --sysroot=%S/Inputs/ami_linux_tree \
-// RUN: | FileCheck --check-prefix=CHECK-LD-AMI %s
-// CHECK-LD-AMI: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
-// CHECK-LD-AMI: "--eh-frame-hdr"
-// CHECK-LD-AMI: "-m" "elf_x86_64"
-// CHECK-LD-AMI: "-dynamic-linker"
-// CHECK-LD-AMI: "{{.*}}/usr/lib/gcc/x86_64-amazon-linux/7{{/|}}crtbegin.o"
-// CHECK-LD-AMI: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-amazon-linux/7"
-// CHECK-LD-AMI:
"-L[[SYSROOT]]/usr/lib/gcc/x86_64-amazon-linux/7/../../../../lib64"
-// CHECK-LD-AMI: "-L[[SYSROOT]]/lib"
-// CHECK-LD-AMI: "-L[[SYSROOT]]/usr/lib"
-// CHECK-LD-AMI: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
-// CHECK-LD-AMI: "-lc"
-// CHECK-LD-AMI: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
+// RUN: | FileCheck --check-prefix=CHECK-LD-AMI-X86_64 %s
+// CHECK-LD-AMI-X86_64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-LD-AMI-X86_64: "--eh-frame-hdr"
+// CHECK-LD-AMI-X86_64: "-m" "elf_x86_64"
+// CHECK-LD-AMI-X86_64: "-dynamic-linker"
+// CHECK-LD-AMI-X86_64:
"{{.*}}/usr/lib/gcc/x86_64-amazon-linux/7{{/|}}crtbegin.o"
+// CHECK-
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
peterwaller-arm wrote: > The CMake build system could be adjusted to make > -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-amazon-linux implied on Amazon Linux, > though. Thanks - Is there precedence for this? Do you have any ideas about how to detect the correct default triple? https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)
peterwaller-arm wrote: Consensus expressed so far seems to be in favour of merging but I'll wait to give further opportunity for comment or objection before merging on Tuesday 8th around 0900 UTC. https://github.com/llvm/llvm-project/pull/109263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
