llvm-ci wrote:
LLVM Buildbot has detected a new failure on builder `clang-x86_64-debian-fast`
running on `gribozavr4` while building `clang` at step 6
"test-build-unified-tree-check-all".
Full details are available at:
https://lab.llvm.org/buildbot/#/builders/56/builds/573
Here is the
https://github.com/sdesmalen-arm closed
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
@@ -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
aemerson wrote:
Why is that restriction there? We often run into
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
@@ -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
sdesmalen-arm wrote:
I don't think so.
The ACLE describes that the SME
@@ -1781,7 +1781,13 @@ void SVEEmitter::createStreamingAttrs(raw_ostream ,
ACLEKind Kind) {
uint64_t VerifyRuntimeMode = getEnumValueForFlag("VerifyRuntimeMode");
uint64_t IsStreamingCompatibleFlag =
getEnumValueForFlag("IsStreamingCompatible");
+
for (auto :
@@ -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}]",
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
@@ -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 {
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
@@ -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
@@ -1781,7 +1781,12 @@ void SVEEmitter::createStreamingAttrs(raw_ostream ,
ACLEKind Kind) {
uint64_t VerifyRuntimeMode = getEnumValueForFlag("VerifyRuntimeMode");
uint64_t IsStreamingCompatibleFlag =
getEnumValueForFlag("IsStreamingCompatible");
+
for (auto :
@@ -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 {
sdesmalen-arm wrote:
Good spot!
@@ -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 {
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
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
@@ -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 {
@@ -1781,7 +1781,12 @@ void SVEEmitter::createStreamingAttrs(raw_ostream ,
ACLEKind Kind) {
uint64_t VerifyRuntimeMode = getEnumValueForFlag("VerifyRuntimeMode");
uint64_t IsStreamingCompatibleFlag =
getEnumValueForFlag("IsStreamingCompatible");
+
for (auto :
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
@@ -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
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
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Sander de Smalen (sdesmalen-arm)
Changes
This allows code with SVE intrinsics to be compiled with +sme,+nosve,
22 matches
Mail list logo
