[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -4419,6 +4419,13 @@ QualType ASTContext::getScalableVectorType(QualType
EltTy, unsigned NumElts,
EltTySize == ElBits && NumElts == (NumEls * NF) && NumFields == 1) {
\
return SingletonId;
\
}
+#define SVE_VECTOR_TYPE_MFLOAT(Name, MangledName, Id, SingletonId, NumEls,
\
+ ElBits, NF)
\
+ if (EltTy->hasIntegerRepresentation() && !EltTy->isBooleanType() &&
\
+ !EltTy->hasSignedIntegerRepresentation() && EltTySize == ElBits &&
\
+ NumElts == (NumEls * NF) && NumFields == 1) {
\
+return SingletonId;
\
+ }
paulwalker-arm wrote:
This is no longer required?
https://github.com/llvm/llvm-project/pull/101644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -69,7 +69,7 @@ #ifndef SVE_VECTOR_TYPE_BFLOAT #define SVE_VECTOR_TYPE_BFLOAT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) \ - SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, false, false, true) + SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, true, false, true) paulwalker-arm wrote: Is this change necessary? https://github.com/llvm/llvm-project/pull/101644 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -700,6 +701,9 @@ class TargetInfo : public TransferrableTargetInfo,
return HasBFloat16 || HasFullBFloat16;
}
+ /// Determine whether the _mfp8 type is supported on this target.
+ virtual bool hasArmMFloat8Type() const { return HasMFloat8; }
paulwalker-arm wrote:
Do we want to be this strict when it comes to using the type? Typically we
don't hide the types behind feature flags anymore because it can make them more
awkward to us. For example, a function declaration referencing `mfloat8_t*`
would fail to compiler despite not requiring an fp8 features.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -3437,8 +3445,8 @@ StringRef BuiltinType::getName(const PrintingPolicy
&Policy) const {
case Id: \
return #ExtType;
#include "clang/Basic/OpenCLExtensionTypes.def"
-#define SVE_TYPE(Name, Id, SingletonId) \
- case Id: \
+#define SVE_TYPE(Name, Id, SingletonId)
\
+ case Id:
\
paulwalker-arm wrote:
Presumably unintentional?
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -5828,6 +5832,7 @@ bool Parser::isKnownToBeTypeSpecifier(const Token &Tok)
const {
case tok::kw__ExtInt:
case tok::kw__BitInt:
case tok::kw___bf16:
+ case tok::kw___mfp8:
paulwalker-arm wrote:
Do you know why this and the similar changes are needed? A quick search
yielded nothing similar for the SVE type names, so just wondering if we're
missing some auto-generation somewhere.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -526,6 +526,11 @@ llvm::Type *CodeGenTypes::ConvertType(QualType T) {
}
case BuiltinType::SveCount:
return llvm::TargetExtType::get(getLLVMContext(), "aarch64.svcount");
+case BuiltinType::ArmMFloat8:
+ ResultType =
+ llvm::VectorType::get(llvm::Type::getInt8Ty(getLLVMContext()),
+llvm::ElementCount::getFixed(1));
+ break;
paulwalker-arm wrote:
Not sure how good an idea this is but what about updating
`getBuiltinVectorTypeInfo` so the code above can be used? I mean, with the new
definition mfloat8_t is effectively a vector type of sorts.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -1391,7 +1391,8 @@ void ASTContext::InitBuiltinTypes(const TargetInfo
&Target,
}
if (Target.hasAArch64SVETypes() ||
- (AuxTarget && AuxTarget->hasAArch64SVETypes())) {
+ (AuxTarget && AuxTarget->hasAArch64SVETypes()) ||
+ Target.hasArmMFloat8Type()) {
paulwalker-arm wrote:
This might be a bum steer but I'm wondering if `Target.hasArmMFloat8Type()` is
needed here. If you ignore the name I think `hasAArch64SVETypes()` effectively
means "are_the_types_defined_in_AArch64SVEACLETypes.def_available?".
If you agree that the new types should not be hidden behind a feature flag then
perhaps the original code just works without alteration.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -2218,6 +2219,11 @@ TypeInfo ASTContext::getTypeInfoImpl(const Type *T)
const {
Width = 0;
\
Align = 16;
\
break;
+#define AARCH64_SCALAR_TYPE(Acronym, Name, MangledName, Id, SingletonId)
paulwalker-arm wrote:
What I meant with my previous comment is that it seems odd to set the define
but then have specify the case block separately, whereas I'd expect something
like
```
#define AARCH64_SCALAR_TYPE(Acronym, Name, MangledName, Id, SingletonId) \
case BuiltinType::Id: \
Width = 8; \
Align = 8; \
break;
```
Note I've used `8` rather than `getChar...`, which is because I don't really
know what those functions do and we know for mfloat8_t we want the exact value
of 8.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -4302,6 +4308,7 @@ ASTContext::getBuiltinVectorTypeInfo(const BuiltinType
*Ty) const {
case BuiltinType::Id:
\
return {BoolTy, llvm::ElementCount::getScalable(NumEls), NF};
#define SVE_OPAQUE_TYPE(Name, MangledName, Id, SingletonId)
paulwalker-arm wrote:
There are a few stale references to `SVE_OPAQUE_TYPE`.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -476,7 +476,6 @@ llvm::Type *CodeGenTypes::ConvertType(QualType T) {
Context.getFloatTypeSemantics(T),
/* UseNativeHalf = */ false);
break;
-
paulwalker-arm wrote:
Unnecessary whitespace change.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -87,6 +87,10 @@ class SVEType {
bool isDefault() const { return DefaultType; }
bool isFloat() const { return Float && !BFloat; }
bool isBFloat() const { return BFloat && !Float; }
paulwalker-arm wrote:
To be consistent I think these need updating to include `&& !MFloat`?
There's also an "isFloatingPoint()" method that probably needs `|| MFloat`.
https://github.com/llvm/llvm-project/pull/101644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -4354,12 +4353,16 @@ ASTContext::getBuiltinVectorTypeInfo(const BuiltinType
*Ty) const {
ElBits, NF)
\
case BuiltinType::Id:
\
return {BFloat16Ty, llvm::ElementCount::getScalable(NumEls), NF};
+#define SVE_VECTOR_TYPE_MFLOAT(Name, MangledName, Id, SingletonId, NumEls,
\
+ ElBits, NF)
\
+ case BuiltinType::Id:
\
+return {getIntTypeForBitwidth(ElBits, false),
\
+llvm::ElementCount::getScalable(NumEls), NF};
#define SVE_PREDICATE_TYPE_ALL(Name, MangledName, Id, SingletonId, NumEls, NF)
\
case BuiltinType::Id:
\
return {BoolTy, llvm::ElementCount::getScalable(NumEls), NF};
#define SVE_OPAQUE_TYPE(Name, MangledName, Id, SingletonId)
#include "clang/Basic/AArch64SVEACLETypes.def"
-
paulwalker-arm wrote:
As above.
https://github.com/llvm/llvm-project/pull/101644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -454,6 +458,8 @@ std::string SVEType::builtin_str() const {
else if (isBFloat()) {
assert(ElementBitwidth == 16 && "Not a valid BFloat.");
S += "y";
+ } else if (isMFloat()) {
+S += "m";
paulwalker-arm wrote:
Perhaps worth adding `assert(ElementBitwidth == 8 && "Not a valid MFloat.")`?
https://github.com/llvm/llvm-project/pull/101644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -87,6 +87,10 @@ class SVEType {
bool isDefault() const { return DefaultType; }
bool isFloat() const { return Float && !BFloat; }
bool isBFloat() const { return BFloat && !Float; }
+ bool isMFloat() const {
+return MFloat && !BFloat && !Float;
+;
paulwalker-arm wrote:
Stray `;`
https://github.com/llvm/llvm-project/pull/101644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -4339,7 +4339,6 @@ ASTContext::getBuiltinVectorTypeInfo(const BuiltinType
*Ty) const {
switch (Ty->getKind()) {
default:
llvm_unreachable("Unsupported builtin vector type");
-
paulwalker-arm wrote:
Please can we keep these blank lines. With all the continuation markers they
help partition the related defines and includes.
https://github.com/llvm/llvm-project/pull/101644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
https://github.com/paulwalker-arm commented: Not sure if there's enough support to update all of them but, but many of the following should be extended to cover the new types: clang/test/CodeGenCXX/aarch64-sve-vector-init.cpp clang/test/CodeGenCXX/aarch64-mangle-sve-fixed-vectors.cpp clang/test/CodeGenCXX/aarch64-mangle-sve-vectors.cpp clang/test/CodeGenCXX/aarch64-sve-fixedtypeinfo.cpp clang/test/CodeGenCXX/aarch64-sve-typeinfo.cpp clang/test/AST/ast-dump-aarch64-sve-types.c clang/test/CodeGen/aarch64-sve.c clang/test/CodeGenObjC/aarch64-sve-types.m clang/test/Sema/aarch64-sve-types.c clang/test/Sema/attr-arm-sve-vector-bits.c clang/test/SemaObjC/aarch64-sve-types.m Is it worth adding the tuple types as well? I'm happy for that to be a separate PR but I figure you'll be touching the same files so it might be easier done together. Your choice. https://github.com/llvm/llvm-project/pull/101644 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
@@ -69,6 +69,11 @@ #ifndef SVE_VECTOR_TYPE_BFLOAT #define SVE_VECTOR_TYPE_BFLOAT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) \ + SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, true, false, true) +#endif + +#ifndef SVE_VECTOR_TYPE_MFLOAT +#define SVE_VECTOR_TYPE_MFLOAT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) \ paulwalker-arm wrote: Is this necessary. Looking at the uses I think `SVE_VECTOR_TYPE_INT` would work? https://github.com/llvm/llvm-project/pull/101644 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG]Add Scalable vectors for mfloat8_t (PR #101644)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/101644 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Fix checkArmStreamingBuiltin for 'sve-b16b16' (PR #109420)
https://github.com/paulwalker-arm approved this pull request. https://github.com/llvm/llvm-project/pull/109420 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
https://github.com/paulwalker-arm closed https://github.com/llvm/llvm-project/pull/110281 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Fix checkArmStreamingBuiltin for 'sve-b16b16' (PR #109420)
@@ -953,9 +953,20 @@ Intrinsic::Intrinsic(StringRef Name, StringRef Proto,
uint64_t MergeTy,
SVEEmitter &Emitter, StringRef SVEGuard,
StringRef SMEGuard)
: Name(Name.str()), LLVMName(LLVMName), Proto(Proto.str()),
- BaseTypeSpec(BT), Class(Class), SVEGuard(SVEGuard.str()),
- SMEGuard(SMEGuard.str()), MergeSuffix(MergeSuffix.str()),
+ BaseTypeSpec(BT), Class(Class), MergeSuffix(MergeSuffix.str()),
BaseType(BT, 'd'), Flags(Flags), ImmChecks(Checks) {
+
+ auto FormatGuard = [](StringRef Guard, StringRef Base) -> std::string {
+if (Guard.empty() || Guard == Base || Guard.starts_with(Base.str() + ","))
+ return Guard.str();
+if (Guard.contains('|'))
+ return Base.str() + ",(" + Guard.str() + ")";
paulwalker-arm wrote:
Would it be safer if this check was first? Or more specifically before the
`Guard.starts_with...` test? Consider `sve,sve-optional|sve2`.
https://github.com/llvm/llvm-project/pull/109420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
@@ -1003,6 +998,13 @@ defm SVFCVT_F32_F64 : SInstCvtMXZ<"svcvt_f32[_f64]",
"MMPd", "MPd", "d", "aarc
defm SVFCVT_F64_F16 : SInstCvtMXZ<"svcvt_f64[_f16]", "ddPO", "dPO", "d",
"aarch64_sve_fcvt_f64f16">;
defm SVFCVT_F64_F32 : SInstCvtMXZ<"svcvt_f64[_f32]", "ddPM", "dPM", "d",
"aarch64_sve_fcvt_f64f32">;
+let SVETargetGuard = "sve,bf16", SMETargetGuard = "sme,bf16" in {
+defm SVCVT_BF16_F32 : SInstCvtMXZ<"svcvt_bf16[_f32]", "$$Pd", "$Pd", "f",
"aarch64_sve_fcvt_bf16f32_v2">;
+
+def SVCVTNT_BF16: SInst<"svcvtnt_bf16[_f32]", "$$Pd", "f", MergeOp1,
"aarch64_sve_fcvtnt_bf16f32_v2", [IsOverloadNone, VerifyRuntimeMode]>;
paulwalker-arm wrote:
Done. I've also renamed the next block of SVCVT definitions to make them
consistent.
https://github.com/llvm/llvm-project/pull/110281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
@@ -5553,6 +5553,14 @@ static SDValue getSVEPredicateBitCast(EVT VT, SDValue
Op, SelectionDAG &DAG) {
if (InVT == VT)
return Op;
+ // Look through casts to when their input has more lanes than
paulwalker-arm wrote:
Done, plus removed another redundant reference to ``.
https://github.com/llvm/llvm-project/pull/110281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
@@ -4072,6 +4078,30 @@ static Value *upgradeX86IntrinsicCall(StringRef Name,
CallBase *CI, Function *F,
return Rep;
}
+static Value *upgradeAArch64IntrinsicCall(StringRef Name, CallBase *CI,
+ Function *F, IRBuilder<> &Builder) {
+ Intrinsic::ID NewID =
+ StringSwitch(Name)
+ .Case("sve.fcvt.bf16f32", Intrinsic::aarch64_sve_fcvt_bf16f32_v2)
+ .Case("sve.fcvtnt.bf16f32", Intrinsic::aarch64_sve_fcvtnt_bf16f32_v2)
+ .Default(Intrinsic::not_intrinsic);
+ if (NewID == Intrinsic::not_intrinsic)
+llvm_unreachable("Unhandled Intrinsic!");
+
+ SmallVector Args(CI->args());
+
+ // The original intrinsics incorrectly used a predicate based on the smallest
+ // element type rather than the largest.
+ Type *PredTy = ScalableVectorType::get(Builder.getInt1Ty(), 4);
+ Args[1] = Builder.CreateIntrinsic(Intrinsic::aarch64_sve_convert_to_svbool,
paulwalker-arm wrote:
Done.
https://github.com/llvm/llvm-project/pull/110281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
https://github.com/paulwalker-arm updated
https://github.com/llvm/llvm-project/pull/110281
>From 7fd66c7630ec03db05203c7ffdf8e36e23e30d93 Mon Sep 17 00:00:00 2001
From: Paul Walker
Date: Thu, 26 Sep 2024 18:07:52 +0100
Subject: [PATCH 1/2] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics.
Affected intrinsics:
llvm.aarch64.sve.fcvt.bf16f32
llvm.aarch64.sve.fcvtnt.bf16f32
The named intrinsics took a predicate based on the smallest element
type when it should be based on the largest. The intrinsics have
been replace by v2 equivalents and affected code ported to use them.
Patch includes changes to getSVEPredicateBitCast() that ensure the
generated code for the auto-upgraded old intrinsics is unchanged.
---
clang/include/clang/Basic/arm_sve.td | 13
.../acle_sve_cvt-bfloat.c | 24 +++---
.../aarch64-sve-intrinsics/acle_sve_cvtnt.c | 16 -
llvm/include/llvm/IR/IntrinsicsAArch64.td | 4 +--
llvm/lib/IR/AutoUpgrade.cpp | 33 +++
.../Target/AArch64/AArch64ISelLowering.cpp| 8 +
.../lib/Target/AArch64/AArch64SVEInstrInfo.td | 4 +--
.../AArch64/AArch64TargetTransformInfo.cpp| 4 +--
llvm/lib/Target/AArch64/SVEInstrFormats.td| 2 +-
.../CodeGen/AArch64/sve-intrinsics-bfloat.ll | 24 --
...sve-intrinsic-comb-all-active-lanes-cvt.ll | 32 +-
.../sve-intrinsic-comb-no-active-lanes-cvt.ll | 4 +--
12 files changed, 115 insertions(+), 53 deletions(-)
diff --git a/clang/include/clang/Basic/arm_sve.td
b/clang/include/clang/Basic/arm_sve.td
index da496e30fbb523..b94a09c94c23e4 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -943,11 +943,6 @@ defm SVFCVTZS_S64_F16 : SInstCvtMXZ<"svcvt_s64[_f16]",
"ddPO", "dPO", "l", "aar
defm SVFCVTZS_S32_F32 : SInstCvtMXZ<"svcvt_s32[_f32]", "ddPM", "dPM", "i",
"aarch64_sve_fcvtzs", [IsOverloadCvt]>;
defm SVFCVTZS_S64_F32 : SInstCvtMXZ<"svcvt_s64[_f32]", "ddPM", "dPM", "l",
"aarch64_sve_fcvtzs_i64f32">;
-let SVETargetGuard = "sve,bf16", SMETargetGuard = "sme,bf16" in {
- defm SVCVT_BF16_F32 : SInstCvtMXZ<"svcvt_bf16[_f32]", "ddPM", "dPM", "b",
"aarch64_sve_fcvt_bf16f32">;
- def SVCVTNT_BF16_F32 : SInst<"svcvtnt_bf16[_f32]", "ddPM", "b", MergeOp1,
"aarch64_sve_fcvtnt_bf16f32", [IsOverloadNone, VerifyRuntimeMode]>;
-}
-
// svcvt_s##_f64
defm SVFCVTZS_S32_F64 : SInstCvtMXZ<"svcvt_s32[_f64]", "ttPd", "tPd", "d",
"aarch64_sve_fcvtzs_i32f64">;
defm SVFCVTZS_S64_F64 : SInstCvtMXZ<"svcvt_s64[_f64]", "ddPN", "dPN", "l",
"aarch64_sve_fcvtzs", [IsOverloadCvt]>;
@@ -1003,6 +998,13 @@ defm SVFCVT_F32_F64 : SInstCvtMXZ<"svcvt_f32[_f64]",
"MMPd", "MPd", "d", "aarc
defm SVFCVT_F64_F16 : SInstCvtMXZ<"svcvt_f64[_f16]", "ddPO", "dPO", "d",
"aarch64_sve_fcvt_f64f16">;
defm SVFCVT_F64_F32 : SInstCvtMXZ<"svcvt_f64[_f32]", "ddPM", "dPM", "d",
"aarch64_sve_fcvt_f64f32">;
+let SVETargetGuard = "sve,bf16", SMETargetGuard = "sme,bf16" in {
+defm SVCVT_BF16_F32 : SInstCvtMXZ<"svcvt_bf16[_f32]", "$$Pd", "$Pd", "f",
"aarch64_sve_fcvt_bf16f32_v2">;
+
+def SVCVTNT_BF16: SInst<"svcvtnt_bf16[_f32]", "$$Pd", "f", MergeOp1,
"aarch64_sve_fcvtnt_bf16f32_v2", [IsOverloadNone, VerifyRuntimeMode]>;
+// SVCVTNT_X_BF16 : Implemented as macro by SveEmitter.cpp
+}
+
let SVETargetGuard = "sve2", SMETargetGuard = "sme" in {
defm SVCVTLT_F32: SInstCvtMX<"svcvtlt_f32[_f16]", "ddPh", "dPh", "f",
"aarch64_sve_fcvtlt_f32f16">;
defm SVCVTLT_F64: SInstCvtMX<"svcvtlt_f64[_f32]", "ddPh", "dPh", "d",
"aarch64_sve_fcvtlt_f64f32">;
@@ -1015,7 +1017,6 @@ def SVCVTNT_F64 : SInst<"svcvtnt_f32[_f64]", "hhPd",
"d", MergeOp1, "aarch6
def SVCVTXNT_F32: SInst<"svcvtxnt_f32[_f64]", "MMPd", "d", MergeOp1,
"aarch64_sve_fcvtxnt_f32f64", [IsOverloadNone, VerifyRuntimeMode]>;
// SVCVTXNT_X_F32 : Implemented as macro by SveEmitter.cpp
-
}
diff --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt-bfloat.c
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt-bfloat.c
index 145d60db6eda3c..cbeac2f384f9a1 100644
--- a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt-bfloat.c
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt-bfloat.c
@@ -24,14 +24,14 @@
// CHECK-LABEL: @test_svcvt_bf16_f32_x(
// CHECK-NEXT: entry:
-// CHECK-NEXT:[[TMP0:%.*]] = tail call
@llvm.aarch64.sve.convert.from.svbool.nxv8i1( [[PG:%.*]])
-// CHECK-NEXT:[[TMP1:%.*]] = tail call
@llvm.aarch64.sve.fcvt.bf16f32( undef,
[[TMP0]], [[OP:%.*]])
+// CHECK-NEXT:[[TMP0:%.*]] = tail call
@llvm.aarch64.sve.convert.from.svbool.nxv4i1( [[PG:%.*]])
+// CHECK-NEXT:[[TMP1:%.*]] = tail call
@llvm.aarch64.sve.fcvt.bf16f32.v2( undef, [[TMP0]], [[OP:%.*]])
// CHECK-NEXT:ret [[TMP1]]
//
// CPP-CHECK-LABEL: @_Z21test_svcvt_bf16_f32_xu10__SVBool_tu13__SVFloat32_t(
// CPP-CHECK
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
@@ -5553,6 +5553,14 @@ static SDValue getSVEPredicateBitCast(EVT VT, SDValue
Op, SelectionDAG &DAG) {
if (InVT == VT)
return Op;
+ // Look through casts to when their input has more lanes than
+ // VT. This will increase the chances of removing casts that introduce new
+ // lanes, which have to be explicitly zero'd.
+ if (Op.getOpcode() == ISD::INTRINSIC_WO_CHAIN &&
+ Op.getConstantOperandVal(0) == Intrinsic::aarch64_sve_convert_to_svbool
&&
paulwalker-arm wrote:
No. At the IR level the conversion is a two step process because you have to
cast through the "svbool" type. i.e. There is no intrinsic that will convert
`` to ``.
https://github.com/llvm/llvm-project/pull/110281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
@@ -5553,6 +5553,14 @@ static SDValue getSVEPredicateBitCast(EVT VT, SDValue
Op, SelectionDAG &DAG) {
if (InVT == VT)
return Op;
+ // Look through casts to when their input has more lanes than
paulwalker-arm wrote:
I knew something was odd when I was writing it but couldn't figure it out :)
I'll change it to `MVT::nxv16i1` if that's ok?
https://github.com/llvm/llvm-project/pull/110281
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64][SVE] Fix definition of bfloat fcvt intrinsics. (PR #110281)
https://github.com/paulwalker-arm created
https://github.com/llvm/llvm-project/pull/110281
Affected intrinsics:
llvm.aarch64.sve.fcvt.bf16f32
llvm.aarch64.sve.fcvtnt.bf16f32
The named intrinsics took a predicate based on the smallest element type when
it should be based on the largest. The intrinsics have been replace by v2
equivalents and affected code ported to use them.
Patch includes changes to getSVEPredicateBitCast() that ensure the generated
code for the auto-upgraded old intrinsics is unchanged.
NOTE: Ignore the first commit, that is
https://github.com/llvm/llvm-project/pull/110278. I'll rebase once it lands.
>From 5bbbaa1458e7ca21bbadfd368ff250226318e2a7 Mon Sep 17 00:00:00 2001
From: Paul Walker
Date: Fri, 27 Sep 2024 15:32:57 +0100
Subject: [PATCH 1/2] [LLVM][Instcombine][SVE] fcvtnt(a,all_active,b) !=
fcvtnt(undef,all_active,b)
The "narrowing top" convert instructions leave the bottom half of
active elements untouched and thus the first paramater of their
associated intrinsic remains live even when there are no inactive
lanes.
---
llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp | 9 +
.../AArch64/sve-intrinsic-comb-all-active-lanes-cvt.ll | 8
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
b/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
index da0798ebf79578..4be236a7827f94 100644
--- a/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
+++ b/llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
@@ -2156,11 +2156,7 @@ AArch64TTIImpl::instCombineIntrinsic(InstCombiner &IC,
case Intrinsic::aarch64_sve_fcvt_f64f32:
case Intrinsic::aarch64_sve_fcvtlt_f32f16:
case Intrinsic::aarch64_sve_fcvtlt_f64f32:
- case Intrinsic::aarch64_sve_fcvtnt_bf16f32:
- case Intrinsic::aarch64_sve_fcvtnt_f16f32:
- case Intrinsic::aarch64_sve_fcvtnt_f32f64:
case Intrinsic::aarch64_sve_fcvtx_f32f64:
- case Intrinsic::aarch64_sve_fcvtxnt_f32f64:
case Intrinsic::aarch64_sve_fcvtzs:
case Intrinsic::aarch64_sve_fcvtzs_i32f16:
case Intrinsic::aarch64_sve_fcvtzs_i32f64:
@@ -2182,6 +2178,11 @@ AArch64TTIImpl::instCombineIntrinsic(InstCombiner &IC,
case Intrinsic::aarch64_sve_ucvtf_f32i64:
case Intrinsic::aarch64_sve_ucvtf_f64i32:
return instCombineSVEAllOrNoActiveUnary(IC, II);
+ case Intrinsic::aarch64_sve_fcvtnt_bf16f32:
+ case Intrinsic::aarch64_sve_fcvtnt_f16f32:
+ case Intrinsic::aarch64_sve_fcvtnt_f32f64:
+ case Intrinsic::aarch64_sve_fcvtxnt_f32f64:
+return instCombineSVENoActiveReplace(IC, II, true);
case Intrinsic::aarch64_sve_st1_scatter:
case Intrinsic::aarch64_sve_st1_scatter_scalar_offset:
case Intrinsic::aarch64_sve_st1_scatter_sxtw:
diff --git
a/llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-comb-all-active-lanes-cvt.ll
b/llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-comb-all-active-lanes-cvt.ll
index 374a9851917685..04550156be30be 100644
---
a/llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-comb-all-active-lanes-cvt.ll
+++
b/llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-comb-all-active-lanes-cvt.ll
@@ -138,7 +138,7 @@ define @test_fcvtnt_bf16_f32( %a, @test_fcvtnt_bf16_f32(
; CHECK-SAME: [[A:%.*]], [[B:%.*]])
{
; CHECK-NEXT:[[PG:%.*]] = tail call
@llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
-; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtnt.bf16f32( undef,
[[PG]], [[B]])
+; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtnt.bf16f32( [[A]],
[[PG]], [[B]])
; CHECK-NEXT:ret [[OUT]]
;
%pg = tail call @llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
@@ -150,7 +150,7 @@ define @test_fcvtnt_f16_f32( %a, @test_fcvtnt_f16_f32(
; CHECK-SAME: [[A:%.*]], [[B:%.*]]) {
; CHECK-NEXT:[[PG:%.*]] = tail call
@llvm.aarch64.sve.ptrue.nxv4i1(i32 31)
-; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtnt.f16f32( undef,
[[PG]], [[B]])
+; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtnt.f16f32( [[A]],
[[PG]], [[B]])
; CHECK-NEXT:ret [[OUT]]
;
%pg = tail call @llvm.aarch64.sve.ptrue.nxv4i1(i32 31)
@@ -162,7 +162,7 @@ define @test_fcvtnt_f32_f64( %a, @test_fcvtnt_f32_f64(
; CHECK-SAME: [[A:%.*]], [[B:%.*]])
{
; CHECK-NEXT:[[PG:%.*]] = tail call
@llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
-; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtnt.f32f64( undef,
[[PG]], [[B]])
+; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtnt.f32f64( [[A]],
[[PG]], [[B]])
; CHECK-NEXT:ret [[OUT]]
;
%pg = tail call @llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
@@ -186,7 +186,7 @@ define @test_fcvtxnt_f32_f64( %a, @test_fcvtxnt_f32_f64(
; CHECK-SAME: [[A:%.*]], [[B:%.*]])
{
; CHECK-NEXT:[[PG:%.*]] = tail call
@llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
-; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve.fcvtxnt.f32f64( undef,
[[PG]], [[B]])
+; CHECK-NEXT:[[OUT:%.*]] = call
@llvm.aarch64.sve
[clang] [Clang][SME2] Use tuple result of SME builtins directly. (PR #109423)
https://github.com/paulwalker-arm closed https://github.com/llvm/llvm-project/pull/109423 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -2986,6 +2986,14 @@ void CastOperation::CheckCStyleCast() {
return;
}
+ if ((DestType->isArmMFloat8Type() && !SrcType->isArmMFloat8Type()) ||
+ (!DestType->isArmMFloat8Type() && SrcType->isArmMFloat8Type())) {
paulwalker-arm wrote:
`DestType->isArmMFloat8Type() != SrcType->isArmMFloat8Type()`?
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/97277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -2644,6 +2644,8 @@ class alignas(TypeAlignment) Type : public
ExtQualsTypeCommonBase {
bool isQueueT() const;// OpenCL queue_t
bool isReserveIDT() const;// OpenCL reserve_id_t
+ bool isArmMFloat8Type() const; // AARCH64_OPAQUE_TYPE
paulwalker-arm wrote:
Are all the `// AARCH64_OPAQUE_TYPE` comments necessary?
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -3437,9 +3446,19 @@ StringRef BuiltinType::getName(const PrintingPolicy
&Policy) const {
case Id: \
return #ExtType;
#include "clang/Basic/OpenCLExtensionTypes.def"
-#define SVE_TYPE(Name, Id, SingletonId) \
- case Id: \
+#define SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId)
\
+ case Id:
\
+return Name;
+#define SVE_OPAQUE_TYPE(Name, MangledName, Id, SingletonId)
\
+ case Id:
\
+return Name;
+#define SVE_PREDICATE_TYPE(Name, MangledName, Id, SingletonId)
\
+ case Id:
\
return Name;
+#define AARCH64_OPAQUE_TYPE(Name, MangledName, Id, SingletonId, NumEls,
\
+ElBits, NF)
+ case ArmMFloat8:
+return "__mfp8";
paulwalker-arm wrote:
I'm not sure which is wrong but I'd expect the returned name to match what it
defined by the `AARCH64_OPAQUE_TYPE`.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -97,6 +97,12 @@ SVE_TYPE(Name, Id, SingletonId) #endif +#ifndef AARCH64_OPAQUE_TYPE +#define AARCH64_OPAQUE_TYPE(Name, MangledName, Id, SingletonId, NumEls, \ +ElBits, NF) \ + SVE_TYPE(Name, Id, SingletonId) +#endif + paulwalker-arm wrote: The `AARCH64_###_TYPE` macros are supposed to take just the four parameters `Name, MangledName, Id, SingletonId` because the intent is for them to be used in generic code where only those parameters are used. Not doing this is why you've had to break several of the `SVE_TYPE` usages apart. I think perhaps you want to define: ``` AARCH64_SCALAR_TYPE(Name, MangledName, Id, SingletonId) ``` and then if you need extra details specific to __mfp8 you'd define `AARCH64_SCALAR_TYPE_MFLOAT`. Depending on the uses it might be the case that you need something below `SVE_TYPE` (e.g. `AARCH64_TYPE`) so there's a macro for all type, and then separate macros for vector and scalar types, each of which are further subdivided base on their need. https://github.com/llvm/llvm-project/pull/97277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -782,6 +782,13 @@ llvm::DIType *CGDebugInfo::CreateType(const BuiltinType
*BT) {
#define SVE_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
#include "clang/Basic/AArch64SVEACLETypes.def"
{
+ if (BT->getKind() == BuiltinType::ArmMFloat8) {
+Encoding = llvm::dwarf::DW_ATE_unsigned_char;
+BTName = BT->getName(CGM.getLangOpts());
+// Bit size and offset of the type.
+uint64_t Size = CGM.getContext().getTypeSize(BT);
+return DBuilder.createBasicType(BTName, Size, Encoding);
+ }
paulwalker-arm wrote:
I think this might be problematic. Whilst using i8 vectors with for vmfloat8_t
is mostly an implementation detail I don't think the same holds for scalar
types.
The problem with using i8 as the backing type is that it means data will be
passed via GPRs instead of FPRs, which is an ABI decision. If the intent is for
such types to be passed via FPRs then I suspect the clang side of things might
have to wait until we've got the LLVM side covered.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -325,6 +325,8 @@ class DeclSpec {
#define HLSL_INTANGIBLE_TYPE(Name, Id, SingletonId)
\
static const TST TST_##Name = clang::TST_##Name;
#include "clang/Basic/HLSLIntangibleTypes.def"
+ // AARCH64_OPAQUE_TYPE
+ static const TST TST_ArmMFloat8_t = clang::TST_ArmMFloat8_t;
paulwalker-arm wrote:
My knowledge here is not great but the comment suggests this is for
enumerations and constants? but given the types are opaque I'm wondering how
like these will be.
There's no C/C++ literal support for fp8 data and any conversation would be
dependent on the value of FPMR and so I'm not sure what level of support we
should be adding.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -2218,6 +2219,12 @@ TypeInfo ASTContext::getTypeInfoImpl(const Type *T)
const {
Width = 0;
\
Align = 16;
\
break;
+#define AARCH64_OPAQUE_TYPE(Name, MangledName, Id, SingletonId, NumEls,
\
+ElBits, NF)
paulwalker-arm wrote:
This define isn't doing anything?
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
https://github.com/paulwalker-arm commented: Sorry, my comments are a bit all over the place, but I'm concerned we've not defined enough (and/or I need to understand what it means to be a storage only type) for me to confidently accept this PR. If possible, my suggestion is to detach the scalar type support from the vector type support because I think the vector side of things is more complete from a specification point of view. https://github.com/llvm/llvm-project/pull/97277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Fix checkArmStreamingBuiltin for 'sve-b16b16' (PR #109420)
@@ -1802,9 +1854,29 @@ void SVEEmitter::createStreamingAttrs(raw_ostream &OS,
ACLEKind Kind) {
if (Def->isFlagSet(IsStreamingFlag))
StreamingMap["ArmStreaming"].insert(Def->getMangledName());
-else if (Def->isFlagSet(VerifyRuntimeMode))
+else if (Def->isFlagSet(VerifyRuntimeMode)) {
+ // Verify that the target guards contain at least one feature that
+ // actually enables SVE or SME (explicitly, or implicitly). This is
needed
+ // for the code in SemaARM.cpp (checkArmStreamingBuiltin) that checks
+ // whether the required runtime mode for an intrinsic matches with the
+ // given set of target features and function attributes.
+ //
+ // The feature lists below must match the disabled features in
+ // 'checkArmStreamingBuiltin'!
+ if (!Def->getSVEGuard().empty() &&
+ !verifyGuard(Def->getSVEGuard(),
+ {"sve", "sve2", "sve2p1", "sve2-aes", "sve2-sha3",
paulwalker-arm wrote:
I suppose you might not need to change arm_sve.td because you could have
`SVETargetGuard(x)` imply `sve,(x)`? Likewise for SME.
https://github.com/llvm/llvm-project/pull/109420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Fix checkArmStreamingBuiltin for 'sve-b16b16' (PR #109420)
@@ -1802,9 +1854,29 @@ void SVEEmitter::createStreamingAttrs(raw_ostream &OS,
ACLEKind Kind) {
if (Def->isFlagSet(IsStreamingFlag))
StreamingMap["ArmStreaming"].insert(Def->getMangledName());
-else if (Def->isFlagSet(VerifyRuntimeMode))
+else if (Def->isFlagSet(VerifyRuntimeMode)) {
+ // Verify that the target guards contain at least one feature that
+ // actually enables SVE or SME (explicitly, or implicitly). This is
needed
+ // for the code in SemaARM.cpp (checkArmStreamingBuiltin) that checks
+ // whether the required runtime mode for an intrinsic matches with the
+ // given set of target features and function attributes.
+ //
+ // The feature lists below must match the disabled features in
+ // 'checkArmStreamingBuiltin'!
+ if (!Def->getSVEGuard().empty() &&
+ !verifyGuard(Def->getSVEGuard(),
+ {"sve", "sve2", "sve2p1", "sve2-aes", "sve2-sha3",
paulwalker-arm wrote:
I very much prefer this idea.
https://github.com/llvm/llvm-project/pull/109420
___
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/paulwalker-arm edited 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/paulwalker-arm approved this pull request. Whilst I understand the rational for requesting an alternate solution, it feels unfair. If the PR was to add a new OS or Vendor I'd have more sympathy but here we're talking about extending the existing OS-Vendor support to cover another target (i.e. x86_64-amazon-linux -> aarch64-amazon-linux) and so it seems fair to do so using the same method and maintain consistency. 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][AArch64] Fix checkArmStreamingBuiltin for 'sve-b16b16' (PR #109420)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/109420 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Fix checkArmStreamingBuiltin for 'sve-b16b16' (PR #109420)
@@ -567,23 +567,28 @@ static bool checkArmStreamingBuiltin(Sema &S, CallExpr
*TheCall,
// * When compiling for SVE only, the caller must be in non-streaming mode.
// * When compiling for both SVE and SME, the caller can be in either mode.
if (BuiltinType == SemaARM::VerifyRuntimeMode) {
-auto DisableFeatures = [](llvm::StringMap &Map, StringRef S) {
- for (StringRef K : Map.keys())
-if (K.starts_with(S))
- Map[K] = false;
-};
-
llvm::StringMap CallerFeatureMapWithoutSVE;
S.Context.getFunctionFeatureMap(CallerFeatureMapWithoutSVE, FD);
-DisableFeatures(CallerFeatureMapWithoutSVE, "sve");
+CallerFeatureMapWithoutSVE["sve"] = false;
+CallerFeatureMapWithoutSVE["sve2"] = false;
+CallerFeatureMapWithoutSVE["sve2p1"] = false;
+// FIXME: This list must be updated with future extensions, because when
+// an intrinsic is enabled by (sve2p1|sme2p1), disabling just "sve" is
+// not sufficient, as the feature dependences are not resolved.
+// At the moment, it should be sufficient to test the 'base' architectural
+// support for SVE and SME, which must always be provided in the
+// target guard. e.g. TargetGuard = "sve-b16b16" without "sme" or "sve"
+// is not sufficient.
paulwalker-arm wrote:
It would be better to add code (SVEEmitter?) to parse the target guards to
ensure there is at least one of the required SVE and SME features referenced.
This should references this code as something to update if the intent really is
to add a new "base" option.
https://github.com/llvm/llvm-project/pull/109420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (PR #108008)
https://github.com/paulwalker-arm closed https://github.com/llvm/llvm-project/pull/108008 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (PR #108008)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/108008 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC][Clang][SVE] Refactor AArch64SVEACLETypes.def to enabled more uses. (PR #107599)
https://github.com/paulwalker-arm closed https://github.com/llvm/llvm-project/pull/107599 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [TBAA] Emit "omnipotent char" for intrinsics with type cast (PR #107793)
paulwalker-arm wrote: I'll need to look to see if the TBAA metadata we're adding matches what we initially envisaged but my gut feeling matches @arsenm. I'm assuming the original code emitted an error, something along the lines of "no version of svst1 available for long long*", which you've "fixed" by introducing a cast that breaks strict aliasing rules. I recall warnings relating to strict aliasing violations being hit and miss? but perhaps we can do better. https://github.com/llvm/llvm-project/pull/107793 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (PR #108008)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/108008 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (PR #108008)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/108008 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][SVE] Change LLVM representation of ACLE tuple types to be struct based. (PR #108008)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/108008 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [NFC][Clang][SVE] Refactor AArch64SVEACLETypes.def to enabled more uses. (PR #107599)
https://github.com/paulwalker-arm updated https://github.com/llvm/llvm-project/pull/107599 >From 05670ea720be07ff8c1645ca90fff00460029de7 Mon Sep 17 00:00:00 2001 From: Paul Walker Date: Fri, 6 Sep 2024 12:10:19 +0100 Subject: [PATCH] [NFC][Clang][SVE] Refactor AArch64SVEACLETypes.def to enabled more uses. Some switch statements require all SVE builtin types to be manually specified. This patch refactors the SVE_*_TYPE macros so that such code can be generated during preprocessing. I've tried to establish a minimal interface that covers all types where no special information is required and then created a set of macros that are dedicated to specific datatypes (i.e. int, float). This patch is groundwork to simplify the changing of SVE tuple types to become struct based as well as work to support the FP8 ACLE. --- .../clang/Basic/AArch64SVEACLETypes.def | 178 +++--- clang/lib/AST/ASTContext.cpp | 162 +--- clang/lib/AST/ItaniumMangle.cpp | 16 +- clang/lib/CodeGen/CodeGenTypes.cpp| 70 ++- 4 files changed, 178 insertions(+), 248 deletions(-) diff --git a/clang/include/clang/Basic/AArch64SVEACLETypes.def b/clang/include/clang/Basic/AArch64SVEACLETypes.def index fa9c1ac0491c45..56e6179a664e26 100644 --- a/clang/include/clang/Basic/AArch64SVEACLETypes.def +++ b/clang/include/clang/Basic/AArch64SVEACLETypes.def @@ -8,28 +8,48 @@ // // This file defines various SVE builtin types. The macros are: // -//SVE_TYPE(Name, Id, SingletonId) - A builtin type that has not been -//covered by any other #define. Defining this macro covers all -//the builtins. +//SVE_TYPE: +//- (Name, MangledName, Id, SingletonId) +//A builtin type that has not been covered by any other #define. Defining +//this macro covers all the builtin types. // -//SVE_VECTOR_TYPE(Name, Id, SingletonId, ElKind, ElBits, IsSigned, IsFP) - -//An SVE scalable vector. +//SVE_VECTOR_TYPE, SVE_PREDICATE_TYPE, SVE_OPAQUE_TYPE: +//- (Name, MangledName, Id, SingletonId) +//A builtin type that has not been covered by any other #define. Defining +//this macro covers the named subset of builtin types. // -//SVE_PREDICATE_TYPE(Name, Id, SingletonId, ElKind) - An SVE scalable -//predicate. +//SVE_VECTOR_TYPE_INT +//- (Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, IsSigned) +//Defining the macro covers the integer vector types. +// +//SVE_VECTOR_TYPE_FLOAT, SVE_VECTOR_TYPE_BFLOAT: +//- (Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) +//Defining the macro covers the floating point vector types. +// +//SVE_PREDICATE_TYPE_ALL: +//- (Name, MangledName, Id, SingletonId, NumEls, NF) +//Defining the macro covers the boolean vector types. // // where: // // - Name is the name of the builtin type. // +// - MangledName is the mangled name of the builtin type. +// // - BuiltinType::Id is the enumerator defining the type. // // - Context.SingletonId is the global singleton of this type. // // - ElKind enumerates the type of the elements. // +// - NumEls enumerates the number of the elements. +// // - ElBits is the size of one element in bits. // +// - NF enumerates the number of sub-vectors. +//TODO: Tuple types are represented as a concatination of "NumEls x ElBits" +//vectors. This will be changed to become a struct containing NF vectors. +// // - IsSigned is true for vectors of signed integer elements and //for vectors of floating-point elements. // @@ -39,102 +59,134 @@ //===--===// #ifndef SVE_VECTOR_TYPE -#define SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId, NumEls, ElBits, \ -IsSigned, IsFP, IsBF) \ +#define SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId) \ SVE_TYPE(Name, Id, SingletonId) #endif +#ifndef SVE_VECTOR_TYPE_DETAILS +#define SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, IsSigned, IsFP, IsBF) \ + SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId) +#endif + +#ifndef SVE_VECTOR_TYPE_BFLOAT +#define SVE_VECTOR_TYPE_BFLOAT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) \ + SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, false, false, true) +#endif + +#ifndef SVE_VECTOR_TYPE_FLOAT +#define SVE_VECTOR_TYPE_FLOAT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) \ + SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, false, true, false) +#endif + +#ifndef SVE_VECTOR_TYPE_INT +#define SVE_VECTOR_TYPE_INT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, IsSigned) \ + SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, IsSigned, false, false) +#endif + #ifndef SVE_PREDICATE_TYPE -#define SVE_PREDICATE_TYPE(Name, MangledName,
[clang] [NFC][Clang][SVE] Refactor AArch64SVEACLETypes.def to enabled more uses. (PR #107599)
https://github.com/paulwalker-arm created https://github.com/llvm/llvm-project/pull/107599 Some switch statements require all SVE builtin types to be manually specified. This patch refactors the SVE_*_TYPE macros so that such code can be generated during preprocessing. I've tried to establish a minimal interface that covers all types where no special information is required and then created a set of macros that are dedicated to specific datatypes (i.e. int, float). This patch is groundwork to simplify the changing of SVE tuple types to become struct based as well as work to support the FP8 ACLE. >From 4c24d0ce0af81962649b3f132f9b9ab715ad134d Mon Sep 17 00:00:00 2001 From: Paul Walker Date: Fri, 6 Sep 2024 12:10:19 +0100 Subject: [PATCH] [NFC][Clang][SVE] Refactor AArch64SVEACLETypes.def to enabled more uses. Some switch statements require all SVE builtin types to be manually specified. This patch refactors the SVE_*_TYPE macros so that such code can be generated during preprocessing. I've tried to establish a minimal interface that covers all types where no special information is required and then created a set of macros that are dedicated to specific datatypes (i.e. int, float). This patch is groundwork to simplify the changing of SVE tuple types to become struct based as well as work to support the FP8 ACLE. --- .../clang/Basic/AArch64SVEACLETypes.def | 178 +++--- clang/lib/AST/ASTContext.cpp | 162 +--- clang/lib/AST/ItaniumMangle.cpp | 16 +- clang/lib/CodeGen/CodeGenTypes.cpp| 70 ++- 4 files changed, 178 insertions(+), 248 deletions(-) diff --git a/clang/include/clang/Basic/AArch64SVEACLETypes.def b/clang/include/clang/Basic/AArch64SVEACLETypes.def index fa9c1ac0491c45..56e6179a664e26 100644 --- a/clang/include/clang/Basic/AArch64SVEACLETypes.def +++ b/clang/include/clang/Basic/AArch64SVEACLETypes.def @@ -8,28 +8,48 @@ // // This file defines various SVE builtin types. The macros are: // -//SVE_TYPE(Name, Id, SingletonId) - A builtin type that has not been -//covered by any other #define. Defining this macro covers all -//the builtins. +//SVE_TYPE: +//- (Name, MangledName, Id, SingletonId) +//A builtin type that has not been covered by any other #define. Defining +//this macro covers all the builtin types. // -//SVE_VECTOR_TYPE(Name, Id, SingletonId, ElKind, ElBits, IsSigned, IsFP) - -//An SVE scalable vector. +//SVE_VECTOR_TYPE, SVE_PREDICATE_TYPE, SVE_OPAQUE_TYPE: +//- (Name, MangledName, Id, SingletonId) +//A builtin type that has not been covered by any other #define. Defining +//this macro covers the named subset of builtin types. // -//SVE_PREDICATE_TYPE(Name, Id, SingletonId, ElKind) - An SVE scalable -//predicate. +//SVE_VECTOR_TYPE_INT +//- (Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, IsSigned) +//Defining the macro covers the integer vector types. +// +//SVE_VECTOR_TYPE_FLOAT, SVE_VECTOR_TYPE_BFLOAT: +//- (Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) +//Defining the macro covers the floating point vector types. +// +//SVE_PREDICATE_TYPE_ALL: +//- (Name, MangledName, Id, SingletonId, NumEls, NF) +//Defining the macro covers the boolean vector types. // // where: // // - Name is the name of the builtin type. // +// - MangledName is the mangled name of the builtin type. +// // - BuiltinType::Id is the enumerator defining the type. // // - Context.SingletonId is the global singleton of this type. // // - ElKind enumerates the type of the elements. // +// - NumEls enumerates the number of the elements. +// // - ElBits is the size of one element in bits. // +// - NF enumerates the number of sub-vectors. +//TODO: Tuple types are represented as a concatination of "NumEls x ElBits" +//vectors. This will be changed to become a struct containing NF vectors. +// // - IsSigned is true for vectors of signed integer elements and //for vectors of floating-point elements. // @@ -39,102 +59,134 @@ //===--===// #ifndef SVE_VECTOR_TYPE -#define SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId, NumEls, ElBits, \ -IsSigned, IsFP, IsBF) \ +#define SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId) \ SVE_TYPE(Name, Id, SingletonId) #endif +#ifndef SVE_VECTOR_TYPE_DETAILS +#define SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, IsSigned, IsFP, IsBF) \ + SVE_VECTOR_TYPE(Name, MangledName, Id, SingletonId) +#endif + +#ifndef SVE_VECTOR_TYPE_BFLOAT +#define SVE_VECTOR_TYPE_BFLOAT(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF) \ + SVE_VECTOR_TYPE_DETAILS(Name, MangledName, Id, SingletonId, NumEls, ElBits, NF, false, false, true) +#endif + +#ifndef SVE_VECTOR_TYPE_FLOAT +#de
[clang] [llvm] [AArch64] Implement intrinsics for SVE FAMIN/FAMAX (PR #99042)
@@ -717,6 +717,11 @@ let Predicates = [HasSVEorSME] in {
defm FDIV_ZPZZ : sve_fp_bin_pred_hfd;
} // End HasSVEorSME
+let Predicates = [HasSVE2orSME2, HasFAMINMAX] in {
+ defm FAMAX_ZPZZ : sve_fp_bin_pred_hfd;
+ defm FAMIN_ZPZZ : sve_fp_bin_pred_hfd;
+}
+
paulwalker-arm wrote:
It doesn't make sense for the pseudo instructions patterns to be so far away
from the definitions of the real instructions. Please move them just below the
defs for FAMIN_ZPmZ/FAMAX_ZPmZ.
https://github.com/llvm/llvm-project/pull/99042
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement intrinsics for SVE FAMIN/FAMAX (PR #99042)
@@ -0,0 +1,115 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 4
+; RUN: llc -mattr=+sve2 < %s | FileCheck %s
+; RUN: llc -mattr=+sme2 -force-streaming < %s | FileCheck %s
+
+target triple = "aarch64-linux"
+
+define @famin_f16( %pg, %a, %b) #0 {
+; CHECK-LABEL: famin_f16:
+; CHECK: // %bb.0:
+; CHECK-NEXT:famin z0.h, p0/m, z0.h, z1.h
+; CHECK-NEXT:ret
+%r = call @llvm.aarch64.sve.famin.nxv8f16( %pg, %a, %b)
+ret %r
+}
+
+define @famin_f32( %pg, %a, %b) #0 {
+; CHECK-LABEL: famin_f32:
+; CHECK: // %bb.0:
+; CHECK-NEXT:famin z0.s, p0/m, z0.s, z1.s
+; CHECK-NEXT:ret
+%r = call @llvm.aarch64.sve.famin.nxv4f32( %pg, %a, %b)
+ret %r
+}
+
+define @famin_f64( %pg, %a, %b) #0 {
+; CHECK-LABEL: famin_f64:
+; CHECK: // %bb.0:
+; CHECK-NEXT:famin z0.d, p0/m, z0.d, z1.d
+; CHECK-NEXT:ret
+%r = call @llvm.aarch64.sve.famin.nxv2f64( %pg, %a, %b)
+ret %r
+}
+
+define @famin_u_f16( %pg, %a, %b) #0 {
+; CHECK-LABEL: famin_u_f16:
+; CHECK: // %bb.0:
+; CHECK-NEXT:famin z0.h, p0/m, z0.h, z1.h
+; CHECK-NEXT:ret
+%r = call @llvm.aarch64.sve.famin.u.nxv8f16( %pg, %a, %b)
paulwalker-arm wrote:
Up to you but it might be worth switching `%a` and `%b` for the calls in the
`_u_` functions. The output should be unchanged, which shows the significance
of the `.u.` in that it frees the register allocator to reuse the second
operand.
https://github.com/llvm/llvm-project/pull/99042
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement intrinsics for SVE FAMIN/FAMAX (PR #99042)
https://github.com/paulwalker-arm approved this pull request. A couple of suggestions but otherwise this looks good to me. https://github.com/llvm/llvm-project/pull/99042 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement intrinsics for SVE FAMIN/FAMAX (PR #99042)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/99042 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement intrinsics for SVE FAMIN/FAMAX (PR #99042)
@@ -135,6 +135,8 @@ enum NodeType : unsigned {
UDIV_PRED,
UMAX_PRED,
UMIN_PRED,
+ FAMAX_PRED,
+ FAMIN_PRED,
paulwalker-arm wrote:
Yep, the latter. We use it here because the ISD node exists for other reasons
and so was convenient to reuse here.
In general the main reason to create `FAMAX_PRED` is when there's optimisation
to be had. In this instance I think it's more likely for us break the
operation into separate FABS_PRED/FMIN_PRED nodes to let the combiner at it,
given it'll be easy to reconstruct the `famin` during isel.
https://github.com/llvm/llvm-project/pull/99042
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Implement intrinsics for SVE FAMIN/FAMAX (PR #99042)
@@ -135,6 +135,8 @@ enum NodeType : unsigned {
UDIV_PRED,
UMAX_PRED,
UMIN_PRED,
+ FAMAX_PRED,
+ FAMIN_PRED,
paulwalker-arm wrote:
Is it necessary to create dedicated AArch64ISD nodes? We normally reserve that
for cases where additional DAG combines are available or for when the operation
is hard to match during ISel, neither of which apply in this case?
https://github.com/llvm/llvm-project/pull/99042
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
paulwalker-arm wrote: Just to add the commit message needs updating to reflect the updated specification. https://github.com/llvm/llvm-project/pull/97277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -3197,6 +3197,13 @@ void CastOperation::CheckCStyleCast() {
}
}
+ if ((DestType->isMFloat8Type() && !SrcType->isMFloat8Type()) ||
+ (!DestType->isMFloat8Type() && SrcType->isMFloat8Type())) {
paulwalker-arm wrote:
`DestType->isMFloat8Type() != SrcType->isMFloat8Type()` ?
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -1139,6 +1139,7 @@ class ASTContext : public RefCountedBase {
CanQualType SatShortFractTy, SatFractTy, SatLongFractTy;
CanQualType SatUnsignedShortFractTy, SatUnsignedFractTy,
SatUnsignedLongFractTy;
+ CanQualType MFloat8Ty;
paulwalker-arm wrote:
For this and all related "in llvm code" naming, do you mind using the
`ArmMFloat8` prefix instead of `MFloat8`? I ask because BFloat16 has an
architecture independent meaning whereas this new type is specific to Arm and
its related builtins.
https://github.com/llvm/llvm-project/pull/97277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64] Add the modal 8 bit floating-point scalar type (PR #97277)
@@ -221,6 +221,10 @@ FLOATING_TYPE(Float128, Float128Ty) // '__ibm128' FLOATING_TYPE(Ibm128, Ibm128Ty) + +// '__fpm8' paulwalker-arm wrote: __mfp8 https://github.com/llvm/llvm-project/pull/97277 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Demote always_inline error to warning for mismatching SME attrs (PR #100740)
https://github.com/paulwalker-arm approved this pull request. https://github.com/llvm/llvm-project/pull/100740 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64]Add Neon vectors for fpm8_t (PR #99865)
paulwalker-arm wrote: Sorry for the noise but I think I've a more wellformed question this time. Is it be possible to use `AArch64SVEACLETypes.def` to reduce some of the boilerplate changes? I'm not sure how much of this is tied to SVE (or rather scalable types) but I'm wondering if clang can be refactored to use `AARCH64_TYPE` for the places where the types do not matter (e.g. when populating enums) and only use `SVE_TYPE` for the places that care about the scalable property. No is a fine answer but when looking at the code I'd rather not have to repeat all these changes for every new AArch64 scalar type we might want in the future. https://github.com/llvm/llvm-project/pull/99865 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CLANG][AArch64]Add Neon vectors for fpm8_t (PR #99865)
paulwalker-arm wrote: Is it possible to use TargetExtType for the scalar type given this is a target specific type. I fully expect LLVM not to support vector's of TargetExtType but I wonder if that can be relaxed given our only use case is to pass them to intrinsics. For anything more exotic we can add intrinsics to cast them to i8 vectors. Alternatively, we could also use TargetExtType for all fp8 scalar and vector types. https://github.com/llvm/llvm-project/pull/99865 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][SveEmitter] Split up TargetGuard into SVE and SME component. (PR #96482)
https://github.com/paulwalker-arm approved this pull request. This is certainly a step in the right direction. https://github.com/llvm/llvm-project/pull/96482 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm approved this pull request. https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -1781,7 +1781,13 @@ void SVEEmitter::createStreamingAttrs(raw_ostream &OS,
ACLEKind Kind) {
uint64_t VerifyRuntimeMode = getEnumValueForFlag("VerifyRuntimeMode");
uint64_t IsStreamingCompatibleFlag =
getEnumValueForFlag("IsStreamingCompatible");
+
for (auto &Def : Defs) {
+if (!Def->isFlagSet(VerifyRuntimeMode) &&
+(Def->getGuard().contains("sve") + Def->getGuard().contains("sme")) ==
+2)
paulwalker-arm wrote:
Surely this is just
```
if (!Def->isFlagSet(VerifyRuntimeMode) && Def->getGuard().contains("sve") &&
Def->getGuard().contains("sme"))
```
isn't it?
https://github.com/llvm/llvm-project/pull/95787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -2264,6 +2278,18 @@ let TargetGuard = "sve2p1" in {
defm SVPMOV_TO_VEC_LANE_D : PMOV_TO_VEC<"svpmov", "lUl",
"aarch64_sve_pmov_to_vector_lane" ,[], ImmCheck1_7>;
}
+let TargetGuard = "sve2p1|sme2p1" in {
+ // DUPQ
+ def SVDUP_LANEQ_B : SInst<"svdup_laneq[_{d}]", "ddi", "cUc", MergeNone,
"aarch64_sve_dup_laneq", [VerifyRuntimeMode], [ImmCheck<1, ImmCheck0_15>]>;
+ def SVDUP_LANEQ_H : SInst<"svdup_laneq[_{d}]", "ddi", "sUsh", MergeNone,
"aarch64_sve_dup_laneq", [VerifyRuntimeMode], [ImmCheck<1, ImmCheck0_7>]>;
+ def SVDUP_LANEQ_S : SInst<"svdup_laneq[_{d}]", "ddi", "iUif", MergeNone,
"aarch64_sve_dup_laneq", [VerifyRuntimeMode], [ImmCheck<1, ImmCheck0_3>]>;
+ def SVDUP_LANEQ_D : SInst<"svdup_laneq[_{d}]", "ddi", "lUld", MergeNone,
"aarch64_sve_dup_laneq", [VerifyRuntimeMode], [ImmCheck<1, ImmCheck0_1>]>;
+}
+
+let TargetGuard = "(sve2p1|sme2),bf16" in {
paulwalker-arm wrote:
This should match the above and thus be "(sve2p1|sme2p1),bf16".
https://github.com/llvm/llvm-project/pull/95787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm commented: With the change of default it's very hard to check everything but we've already agreed there'll need to be a full audit once all the inflight work has landed. I did spot one thing though: Should the integer svclamp and svrevd builtins be protected by "sve2p1|sme" rather than "sve2p1|sme2"? https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -286,17 +290,20 @@ let TargetGuard = "sve,f64mm,bf16" in {
}
let TargetGuard = "sve,bf16" in {
+ def SVBFMMLA : SInst<"svbfmmla[_{0}]", "MMdd", "b", MergeNone,
"aarch64_sve_bfmmla", [IsOverloadNone]>;
+}
+
+let TargetGuard = "(sve|sme),bf16" in {
def SVBFDOT: SInst<"svbfdot[_{0}]","MMdd", "b", MergeNone,
"aarch64_sve_bfdot",[IsOverloadNone, VerifyRuntimeMode]>;
def SVBFMLALB : SInst<"svbfmlalb[_{0}]", "MMdd", "b", MergeNone,
"aarch64_sve_bfmlalb", [IsOverloadNone, VerifyRuntimeMode]>;
def SVBFMLALT : SInst<"svbfmlalt[_{0}]", "MMdd", "b", MergeNone,
"aarch64_sve_bfmlalt", [IsOverloadNone, VerifyRuntimeMode]>;
- def SVBFMMLA : SInst<"svbfmmla[_{0}]", "MMdd", "b", MergeNone,
"aarch64_sve_bfmmla", [IsOverloadNone, VerifyRuntimeMode]>;
def SVBFDOT_N : SInst<"svbfdot[_n_{0}]", "MMda", "b", MergeNone,
"aarch64_sve_bfdot",[IsOverloadNone, VerifyRuntimeMode]>;
def SVBFMLAL_N : SInst<"svbfmlalb[_n_{0}]","MMda", "b", MergeNone,
"aarch64_sve_bfmlalb", [IsOverloadNone, VerifyRuntimeMode]>;
paulwalker-arm wrote:
Not relevant to this patch but there's a typo here `SVBFMLAL_N` should
`SVBFMLALB_N`.
https://github.com/llvm/llvm-project/pull/95787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -17,7 +25,7 @@ // CPP-CHECK-NEXT:[[TMP1:%.*]] = shl nuw nsw i64 [[TMP0]], 4 // CPP-CHECK-NEXT:ret i64 [[TMP1]] // -uint64_t test_svcntb() +uint64_t test_svcntb(void) MODE_ATTR paulwalker-arm wrote: Is there a problem we need to worry about with using the SME keywords with `()` functions? https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -286,10 +290,13 @@ let TargetGuard = "sve,f64mm,bf16" in {
}
let TargetGuard = "sve,bf16" in {
+ def SVBFMMLA : SInst<"svbfmmla[_{0}]", "MMdd", "b", MergeNone,
"aarch64_sve_bfmmla", [IsOverloadNone]>;
+}
+
+let TargetGuard = "(sve,bf16)|sme" in {
paulwalker-arm wrote:
Looking at the specification suggests this should be `(sve|sme),bf16`?
Also, the closing `}` could do with a matching comment.
https://github.com/llvm/llvm-project/pull/95787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -1781,7 +1781,12 @@ void SVEEmitter::createStreamingAttrs(raw_ostream &OS,
ACLEKind Kind) {
uint64_t VerifyRuntimeMode = getEnumValueForFlag("VerifyRuntimeMode");
uint64_t IsStreamingCompatibleFlag =
getEnumValueForFlag("IsStreamingCompatible");
+
for (auto &Def : Defs) {
+assertDef->getGuard().contains("sve") +
+ Def->getGuard().contains("sme")) <= 1) ||
+Def->isFlagSet(VerifyRuntimeMode)) &&
paulwalker-arm wrote:
Given this is a build time error that represents a bug in `arm_sve.td`, do you
think it's worth using `llvm_unreachable` rather than an assert?
https://github.com/llvm/llvm-project/pull/95787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
@@ -2264,6 +2278,18 @@ let TargetGuard = "sve2p1" in {
defm SVPMOV_TO_VEC_LANE_D : PMOV_TO_VEC<"svpmov", "lUl",
"aarch64_sve_pmov_to_vector_lane" ,[], ImmCheck1_7>;
}
+let TargetGuard = "sve2p1|sme2" in {
paulwalker-arm wrote:
I think this is a sme2p1 feature?
https://github.com/llvm/llvm-project/pull/95787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Expose compatible SVE intrinsics with only +sme (PR #95787)
https://github.com/paulwalker-arm commented: Not for this patch but I do wonder if there's value in protecting non-bf16 instruction backed builtins (e.g. loadstone and shuffles) with the bf16 target guard. I figure we'll either error on the use of the `svbfloat` type or the code generation should just work and thus there's be no reason to artificially restrict user code. https://github.com/llvm/llvm-project/pull/95787 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
https://github.com/paulwalker-arm approved this pull request. https://github.com/llvm/llvm-project/pull/93802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
@@ -559,31 +559,76 @@ SemaARM::ArmStreamingType getArmStreamingFnType(const
FunctionDecl *FD) {
return SemaARM::ArmNonStreaming;
}
-static void checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
- const FunctionDecl *FD,
- SemaARM::ArmStreamingType BuiltinType) {
+static bool checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
+ FunctionDecl *FD,
paulwalker-arm wrote:
Can `FD`'s constness be restored? I think you only had to remove it because
you previously called `getODRHash`.
https://github.com/llvm/llvm-project/pull/93802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
@@ -622,7 +679,8 @@ bool SemaARM::CheckSMEBuiltinFunctionCall(unsigned
BuiltinID,
}
if (BuiltinType)
- checkArmStreamingBuiltin(SemaRef, TheCall, FD, *BuiltinType);
+ HasError |= checkArmStreamingBuiltin(SemaRef, TheCall, FD, *BuiltinType,
paulwalker-arm wrote:
Would it be wrong to return immediately? I ask because there's
```
switch (BuiltinID) {
default:
return false;
```
which should be `return HasError;`? but if we can return directly then there's
less change of other similar issues.
https://github.com/llvm/llvm-project/pull/93802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
@@ -559,31 +559,86 @@ SemaARM::ArmStreamingType getArmStreamingFnType(const
FunctionDecl *FD) {
return SemaARM::ArmNonStreaming;
}
-static void checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
- const FunctionDecl *FD,
- SemaARM::ArmStreamingType BuiltinType) {
+static bool checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
+ FunctionDecl *FD,
+ SemaARM::ArmStreamingType BuiltinType,
+ unsigned BuiltinID) {
SemaARM::ArmStreamingType FnType = getArmStreamingFnType(FD);
- if (BuiltinType == SemaARM::ArmStreamingOrSVE2p1) {
-// Check intrinsics that are available in [sve2p1 or sme/sme2].
-llvm::StringMap CallerFeatureMap;
-S.Context.getFunctionFeatureMap(CallerFeatureMap, FD);
-if (Builtin::evaluateRequiredTargetFeatures("sve2p1", CallerFeatureMap))
- BuiltinType = SemaARM::ArmStreamingCompatible;
-else
+
+ // Check if the intrinsic is available in the right mode, i.e.
+ // * When compiling for SME only, the caller must be in streaming mode.
+ // * When compiling for SVE only, the caller must be in non-streaming mode.
+ // * When compiling for both SVE and SME, the caller can be in either mode.
+ if (BuiltinType == SemaARM::VerifyRuntimeMode) {
+static llvm::StringMap CallerFeatureMapWithoutSVE,
+CallerFeatureMapWithoutSME;
paulwalker-arm wrote:
I hope I'm wrong but I think the use of static here is almost certainly bad
because there's nothing stopping multiple threads from calling
`checkArmStreamingBuiltin`. I looked for other instances but all I could find
involved one time static initialisation after which the data is effectively
constant.
Random Idea:
Rather than filtering the feature map you could process `BuiltinTargetGuards`,
by which I mean you could split the guard into streaming and non-streaming
(perhaps that's what `|` effectively means) and then you use whichever side is
relevant to the function's mode of operation.
Of course you could just remove the cache and leave compile time as a worry for
tomorrow.
https://github.com/llvm/llvm-project/pull/93802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
@@ -559,31 +559,86 @@ SemaARM::ArmStreamingType getArmStreamingFnType(const
FunctionDecl *FD) {
return SemaARM::ArmNonStreaming;
}
-static void checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
- const FunctionDecl *FD,
- SemaARM::ArmStreamingType BuiltinType) {
+static bool checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
+ FunctionDecl *FD,
+ SemaARM::ArmStreamingType BuiltinType,
+ unsigned BuiltinID) {
SemaARM::ArmStreamingType FnType = getArmStreamingFnType(FD);
- if (BuiltinType == SemaARM::ArmStreamingOrSVE2p1) {
-// Check intrinsics that are available in [sve2p1 or sme/sme2].
-llvm::StringMap CallerFeatureMap;
-S.Context.getFunctionFeatureMap(CallerFeatureMap, FD);
-if (Builtin::evaluateRequiredTargetFeatures("sve2p1", CallerFeatureMap))
- BuiltinType = SemaARM::ArmStreamingCompatible;
-else
+
+ // Check if the intrinsic is available in the right mode, i.e.
+ // * When compiling for SME only, the caller must be in streaming mode.
+ // * When compiling for SVE only, the caller must be in non-streaming mode.
+ // * When compiling for both SVE and SME, the caller can be in either mode.
+ if (BuiltinType == SemaARM::VerifyRuntimeMode) {
+static llvm::StringMap CallerFeatureMapWithoutSVE,
+CallerFeatureMapWithoutSME;
+
+// Cache the feature maps, to avoid having to recalculate this for each
+// builtin call.
+static unsigned CachedODRHash = 0;
paulwalker-arm wrote:
As above.
https://github.com/llvm/llvm-project/pull/93802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Fix feature flags dependecies (PR #90612)
paulwalker-arm wrote: @momchil-velikov's commentary applies globally and is not specific to FPMR. Which is to say, Arm switched a while back from "all system register need to be protected by their feature flag" to "only protect system registers where there is a need". The rational is that we see it as being unnecessarily burdensome to asm writers to force them to use a feature flag in order to use the pretty printed version of an instruction they can already emit (this is especially true when dynamic feature detection is used, rather than wanting to explicitly say the feature must be present) . We've no direct plans to revisit all previously implemented system registers unless there's a specific need. https://github.com/llvm/llvm-project/pull/90612 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/93802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
@@ -561,16 +561,61 @@ SemaARM::ArmStreamingType getArmStreamingFnType(const
FunctionDecl *FD) {
static void checkArmStreamingBuiltin(Sema &S, CallExpr *TheCall,
const FunctionDecl *FD,
- SemaARM::ArmStreamingType BuiltinType) {
+ SemaARM::ArmStreamingType BuiltinType,
+ unsigned BuiltinID) {
SemaARM::ArmStreamingType FnType = getArmStreamingFnType(FD);
- if (BuiltinType == SemaARM::ArmStreamingOrSVE2p1) {
-// Check intrinsics that are available in [sve2p1 or sme/sme2].
-llvm::StringMap CallerFeatureMap;
-S.Context.getFunctionFeatureMap(CallerFeatureMap, FD);
-if (Builtin::evaluateRequiredTargetFeatures("sve2p1", CallerFeatureMap))
+
+ // Check if the intrinsic is available in the right mode, i.e.
+ // * When compiling for SME only, the caller must be in streaming mode.
+ // * When compiling for SVE only, the caller must be in non-streaming mode.
+ // * When compiling for both SVE and SME, the caller can be in either mode.
+ if (BuiltinType == SemaARM::ArmStreamingOrHasSVE) {
+static const FunctionDecl *CachedFD = nullptr;
+bool SatisfiesSVE = false, SatisfiesSME = false;
+
+if (FD != CachedFD) {
+ // We know the builtin requires either some combination of SVE flags, or
+ // some combination of SME flags, but we need to figure out which part
+ // of the required features is satisfied by the target features.
+ //
+ // For a builtin with target guard 'sve2p1|sme2', if we compile with
+ // '+sve2p1,+sme', then we know that it satisfies the 'sve2p1' part if we
+ // evaluate the features for '+sve2p1,+sme,+nosme'.
+ //
+ // Similarly, if we compile with '+sve2,+sme2', then we know it satisfies
+ // the 'sme2' part if we evaluate the features for '+sve2,+sme2,+nosve'.
+ llvm::StringMap CallerFeatureMap;
+ auto DisableFeatures = [&CallerFeatureMap](StringRef S) {
+for (StringRef K : CallerFeatureMap.keys())
+ if (K.starts_with(S))
+CallerFeatureMap[K] = false;
+ };
+
+ StringRef BuiltinTargetGuards(
+ S.Context.BuiltinInfo.getRequiredFeatures(BuiltinID));
+
+ S.Context.getFunctionFeatureMap(CallerFeatureMap, FD);
+ DisableFeatures("sme");
+ SatisfiesSVE = Builtin::evaluateRequiredTargetFeatures(
+ BuiltinTargetGuards, CallerFeatureMap);
+
+ S.Context.getFunctionFeatureMap(CallerFeatureMap, FD);
+ DisableFeatures("sve");
+ SatisfiesSME = Builtin::evaluateRequiredTargetFeatures(
+ BuiltinTargetGuards, CallerFeatureMap);
+
+ CachedFD = FD;
+}
+
+if (SatisfiesSVE && SatisfiesSME)
paulwalker-arm wrote:
Does this effectively prevent streaming compatible functions when only SVE
feature flags are available?
My updated understand of streaming compatible functions is that SME features
play no role and the user is expected to use SVE feature flags to direct the
compiler to the level of SVE support a streaming compatible function can have,
much like they would for ordinary functions.
https://github.com/llvm/llvm-project/pull/93802
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
@@ -225,7 +225,7 @@ def IsStreamingCompatible : FlagType<0x40>; def IsReadZA: FlagType<0x80>; def IsWriteZA : FlagType<0x100>; def IsReductionQV : FlagType<0x200>; -def IsStreamingOrSVE2p1 : FlagType<0x400>; // Use for intrinsics that are common between sme/sme2 and sve2p1. +def IsSVEOrStreamingSVE : FlagType<0x400>; // Use for intrinsics that are common between SVE and SME. paulwalker-arm wrote: If you permit a bit of bike shedding I don't think this is a good name. From what I can see the new flag is used to trigger dynamic resolution to determine if the builtin is available to use based on the target features along with any keywords associated with the function. Perhaps `RequiresDynamicVerification`? or ideally something shorter that has the same meaning. https://github.com/llvm/llvm-project/pull/93802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/93802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Generalise streaming mode checks for builtins. (PR #93802)
https://github.com/paulwalker-arm requested changes to this pull request. https://github.com/llvm/llvm-project/pull/93802 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Use __clang_arm_builtin_alias for overloaded svreinterpret's (PR #92427)
https://github.com/paulwalker-arm approved this pull request. https://github.com/llvm/llvm-project/pull/92427 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
https://github.com/paulwalker-arm approved this pull request. https://github.com/llvm/llvm-project/pull/91356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/91356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
https://github.com/paulwalker-arm commented: After further discussion I know understand the `__arm_streaming_compatible` keyword has no affect on the target features in play and only tells the compiler not to emit any SM state changing instructions as part of the calling convention. https://github.com/llvm/llvm-project/pull/91356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
@@ -8982,11 +8982,18 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD)
{
const FunctionDecl *FD = cast(CurContext);
llvm::StringMap CallerFeatureMap;
Context.getFunctionFeatureMap(CallerFeatureMap, FD);
-if (!Builtin::evaluateRequiredTargetFeatures(
-"sve", CallerFeatureMap)) {
- Diag(NewVD->getLocation(), diag::err_sve_vector_in_non_sve_target) << T;
- NewVD->setInvalidDecl();
- return;
paulwalker-arm wrote:
Is dropping the immediate return upon setting up a diagnostic intentional?
https://github.com/llvm/llvm-project/pull/91356
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
@@ -9,6 +9,12 @@ #include +#if defined __ARM_FEATURE_SME +#define MODE_ATTR __arm_streaming +#else +#define MODE_ATTR __arm_streaming_compatible paulwalker-arm wrote: Do you need to use `__arm_streaming_compatible` here? Now we've agreed this keyword has no effect on the target features in use I think `MODE_ATTR` should remain blank to mirror the expected usage when SME is not in use. https://github.com/llvm/llvm-project/pull/91356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
https://github.com/paulwalker-arm edited https://github.com/llvm/llvm-project/pull/91356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang][AArch64] Require SVE or SSVE for scalable types. (PR #91356)
https://github.com/paulwalker-arm requested changes to this pull request. As discussed offline, I don't think we want to be this strict. As demonstrated by the changes to the ACLE tests, this change makes it impossible to distribute a library in binary form that can work for both SVE and InStreamingMode environments. I believe functions decorated with `__arm_streaming_compatible` should be allowed to assume the presence of the subset of instructions that is available to both environments. Library users get protected at the point they call such functions whereby a compilation error is emitted when the caller either doesn't have access to SVE or is not in streaming mode. https://github.com/llvm/llvm-project/pull/91356 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
