[mlir][ArmSME] Add tests for Streaming SVE

[c-rhodes]

Summary

This patch adds a couple of tests for targeting Arm Streaming SVE (SSVE)
mode, part of the Arm Scalable Matrix Extension (SME).

SSVE is enabled in the backend at the function boundary by specifying
the aarch64_pstate_sm_enabled attribute, as documented here [1]. SSVE
can be targeted from MLIR by specifying this in the passthrough
attributes [2] and compiling with

-mattr=+sme,+sve -force-streaming-compatible-sve

The passthrough will propagate to the backend where smstart/smstop
will be emitted around the call to the SSVE function.

The set of legal instructions changes in SSVE,
-force-streaming-compatible-sve avoids the use of NEON entirely and
instead lowers to (streaming-compatible) SVE. The behaviour this flag
predicates will be hooked up to the function attribute in the future
such that simply specifying this (should) lead to correct
code-generation.

Two tests are added:

• A basic LLVMIR test verifying the attribute is passed through.
• An integration test calling a SSVE function.

The integration test can be run with QEMU.

[1] https://llvm.org/docs/AArch64SME.html
[2] https://mlir.llvm.org/docs/Dialects/LLVM/#attribute-pass-through

[awarzynski]

@c-rhodes , thanks for working on this, this is a major milestone for Arm's SME! :)

IIUC, these tests won't work unless run via an emulator. It would be good to document what emulator is needed and to disable these tests unless ARM_EMULATOR_EXECUTABLE is also specified.

Also, whenever testing on SVE hardware, we should avoid using an emulator to run SVE integration tests. Even if SME integration tests are enabled. We probably need ARM_SME_EMULATOR_EXECUTABLE so that:

• ARM_EMULATOR_EXECUTABLE -> run Arm SVE integration tests via an emulator (optional, doesn't affect SME/SSVE integration tests),
• ARM_SME_EMULATOR_EXECUTABLE -> defines the emulator to use for the Arm SME integration tests (required whenever MLIR_RUN_ARM_SME_TESTS is set, doesn't affect SVE integration tests),

@DavidSpickett , it would be great if we could run these on clang-aarch64-sve-vla. Any chance QEMU 7.1.0 is available there? (or could be installed from GitHub?)

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

In the spirit of https://reviews.llvm.org/D148005, could you use mlir-cpu-runner instead?

mlir/test/Target/LLVMIR/arm-ssve.mlir

11

How about testing for smstart and smstop? Given how crucial these two instructions are, I think that that would be worthwhile.

[DavidSpickett]

@DavidSpickett , it would be great if we could run these on clang-aarch64-sve-vla. Any chance QEMU 7.1.0 is available there? (or could be installed from GitHub?)

We're on focal Ubuntu so it's certainly not in apt but happy to install it. Please confirm that the tests actually pass on 7.1.0 and don't hit bugs in QEMU.

[DavidSpickett]

Also, whenever testing on SVE hardware, we should avoid using an emulator to run SVE integration tests. Even if SME integration tests are enabled. We probably need ARM_SME_EMULATOR_EXECUTABLE so that:

Instead of enumerating the extension names you could keep the option global, and we just setup a non SVE bot to run SME and SVE tests on qemu.

For example:
clang-aarch64-sve-vla sets MLIR_RUN_ARM_SVE_TESTS=ON and runs SVE tests natively
clang-aarch64-full-2stage sets MLIR_RUN_ARM_SVE_TESTS=ON, MLIR_RUN_ARM_SME_TESTS=ON, ARM_EMULATOR_EXECUTABLE=<qemu> and runs everything under emulation

The majority of people at this point have neither SVE or SME, so adding a bunch of emulator options for this only serves the bots.

Overall, these tests should probably check actual host features but that looks like a more involved change. As in, a test should say "I want SVE" and whether SVE is got from hardware or emulator, that's up to lit to resolve. But don't attempt that in this change :)

[c-rhodes]

In D148111#4261592, @awarzynski wrote:

@c-rhodes , thanks for working on this, this is a major milestone for Arm's SME! :)

IIUC, these tests won't work unless run via an emulator. It would be good to document what emulator is needed and to disable these tests unless ARM_EMULATOR_EXECUTABLE is also specified.

Happy to document what's needed but by disabling these tests unless an emulator is specified are we not just creating work for ourselves in the future? If you build the Arm SME integration tests and get SIGILLs running them on unsupported hardware that's on you?

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

In the spirit of https://reviews.llvm.org/D148005, could you use mlir-cpu-runner instead?

Sure I can base this on your patch.

mlir/test/Target/LLVMIR/arm-ssve.mlir

11

How about testing for smstart and smstop? Given how crucial these two instructions are, I think that that would be worthwhile.

That's tested in the backend, I don't see any value in duplicating that in MLIR.

[c-rhodes]

In D148111#4261631, @DavidSpickett wrote:

@DavidSpickett , it would be great if we could run these on clang-aarch64-sve-vla. Any chance QEMU 7.1.0 is available there? (or could be installed from GitHub?)

We're on focal Ubuntu so it's certainly not in apt but happy to install it. Please confirm that the tests actually pass on 7.1.0 and don't hit bugs in QEMU.

Cheers! I've just tested the SVE and SME integration tests pass on 7.1.0.

[c-rhodes]

In D148111#4261645, @DavidSpickett wrote:

Also, whenever testing on SVE hardware, we should avoid using an emulator to run SVE integration tests. Even if SME integration tests are enabled. We probably need ARM_SME_EMULATOR_EXECUTABLE so that:

Instead of enumerating the extension names you could keep the option global, and we just setup a non SVE bot to run SME and SVE tests on qemu.

For example:
clang-aarch64-sve-vla sets MLIR_RUN_ARM_SVE_TESTS=ON and runs SVE tests natively
clang-aarch64-full-2stage sets MLIR_RUN_ARM_SVE_TESTS=ON, MLIR_RUN_ARM_SME_TESTS=ON, ARM_EMULATOR_EXECUTABLE=<qemu> and runs everything under emulation

The majority of people at this point have neither SVE or SME, so adding a bunch of emulator options for this only serves the bots.

Overall, these tests should probably check actual host features but that looks like a more involved change. As in, a test should say "I want SVE" and whether SVE is got from hardware or emulator, that's up to lit to resolve. But don't attempt that in this change :)

I agree with everything you've said here :)

[DavidSpickett]

Cheers! I've just tested the SVE and SME integration tests pass on 7.1.0.

Thanks, I'll get this installed onto the bots.

However you want to wire up the cmake options, we can do that over in llvm-zorg.

[awarzynski]

In D148111#4261797, @c-rhodes wrote:

In D148111#4261592, @awarzynski wrote:

@c-rhodes , thanks for working on this, this is a major milestone for Arm's SME! :)

IIUC, these tests won't work unless run via an emulator. It would be good to document what emulator is needed and to disable these tests unless ARM_EMULATOR_EXECUTABLE is also specified.

but by disabling these tests unless an emulator is specified are we not just creating work for ourselves in the future? If you build the Arm SME integration tests and get SIGILLs running them on unsupported hardware that's on you?

I don't necessarily agree and others might see this differently too. We know that these tests do require an emulator and that this is unlikely to change in the near future. So a user getting a SIGILL could argue that a configuration _without_ an emulator shouldn't be possible/enabled at all. But whether that's on the user or the developer is secondary, IMHO. What's more important is that we can make everyone's lives a bit easier and make sure that configs that are not supported (i.e. _without_ emulation) are also not implemented. Yes, one person would have to update this config once SME hardware is available, but that's a low price to pay in my view. I am happy to volunteer for that. In any case, this is a nice-to-have, not a blocker.

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

Just to clarify - you won't need to rebase this on top of D148005 to use mlir-cpu-runner (SVE and SME tests do not share their lit.local.cfg ATM, right?)

mlir/test/Target/LLVMIR/arm-ssve.mlir

11

That's tested in the backend, I don't see any value in duplicating that in MLIR.

I think that that's a bit more nuanced than this.

1. I couldn't find a test in the backend that would specifically verify that aarch64_pstate_sm_enabled --> smstart + smstop (though there are tests that would fail if this condition no longer holds, e.g. sme-streaming-body.ll)
2. One can argue that "LLVM IR MLIR dialect" --> "LLVM IR" translation is already thoroughly tested in MLIR, so there's no need for another test at all (i.e. "mlir/test/Target/LLVMIR/arm-ssve.mlir" is not needed).

A couple of other points:

• To me, aarch64_pstate_sm_enabled is an LLVM implementation detail. From the point of view of "SME integration", I'm more interested in making sure that there's a mechanism in MLIR to take us from said mechanism to smstart/smstop. Yes, this sort of low level hardware details are normally a domain of LLVM backends, but it's unavoidable for integration tests to cross the boundaries of sub-projects. This would be only one test to verify the most fundamental part of the SME extension.
• This would also be a nice way of documenting what the purpose of this attribute is (again, this information is available in various places, but it would be nice to make it obvious for folks working primarily on MLIR). Also, llc is already available in MLIR.

Admittedly, other the tests in this directory focus on LLVM IR and I am thinking about another "integration test". So this would need to go elsewhere. As for duplication - there's probably over 100k tests in llvm-project (I haven't checked) - having one extra test would have negligible impact.

Again, not a blocker, just a nice-to-have. I mostly wanted to share my rationale for the suggestion. I'm definitely in favor of keeping this test.

[DavidSpickett]

QEMU is now available on our AArch64 bots:

root@linaro-clang-aarch64-lld-2stage:/# qemu-aarch64 --version
qemu-aarch64 version 7.1.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

Please put up a patch for llvm-zorg to setup the bots.

[c-rhodes]

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

Just to clarify - you won't need to rebase this on top of D148005 to use mlir-cpu-runner (SVE and SME tests do not share their lit.local.cfg ATM, right?)

Your patch adds the mlir-cpu-runner executable to the top-level mlir/test Lit config, only a small change so I guess I could do the same change here.

mlir/test/Target/LLVMIR/arm-ssve.mlir

11

1. I couldn't find a test in the backend that would specifically verify that aarch64_pstate_sm_enabled --> smstart + smstop (though there are tests that would fail if this condition no longer holds, e.g. sme-streaming-body.ll)

https://github.com/llvm/llvm-project/blob/e3175f7f1b55a38e9ab845ca26f0c4343ee2f7ff/llvm/test/CodeGen/AArch64/sme-streaming-interface.ll#L29

2. One can argue that "LLVM IR MLIR dialect" --> "LLVM IR" translation is already thoroughly tested in MLIR, so there's no need for another test at all (i.e. "mlir/test/Target/LLVMIR/arm-ssve.mlir" is not needed).

That's a fair point and did cross my mind, that test is effectively testing the passthrough mechanism which is already tested so it could be removed.

A couple of other points:

• To me, aarch64_pstate_sm_enabled is an LLVM implementation detail. From the point of view of "SME integration", I'm more interested in making sure that there's a mechanism in MLIR to take us from said mechanism to smstart/smstop. Yes, this sort of low level hardware details are normally a domain of LLVM backends, but it's unavoidable for integration tests to cross the boundaries of sub-projects. This would be only one test to verify the most fundamental part of the SME extension.
• This would also be a nice way of documenting what the purpose of this attribute is (again, this information is available in various places, but it would be nice to make it obvious for folks working primarily on MLIR). Also, llc is already available in MLIR.

Admittedly, other the tests in this directory focus on LLVM IR and I am thinking about another "integration test". So this would need to go elsewhere. As for duplication - there's probably over 100k tests in llvm-project (I haven't checked) - having one extra test would have negligible impact.

Again, not a blocker, just a nice-to-have. I mostly wanted to share my rationale for the suggestion. I'm definitely in favor of keeping this test.

The MLIR testing guidelines don't seem to mention anything about testing code-generation and I only see a single test using llc so I'm hesitant to add such a test given there's not a strong precedent and there is coverage in the backend testing smstart/smstop are emitted for this IR.

[c-rhodes]

In D148111#4264730, @DavidSpickett wrote:

QEMU is now available on our AArch64 bots:

root@linaro-clang-aarch64-lld-2stage:/# qemu-aarch64 --version
qemu-aarch64 version 7.1.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

Please put up a patch for llvm-zorg to setup the bots.

Thanks for installing! Will do.

[c-rhodes]

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

In the spirit of https://reviews.llvm.org/D148005, could you use mlir-cpu-runner instead?

Ah, just realised mlir-cpu-runner doesn't support -force-streaming-compatible-sve flag. It will be possible to use mlir-cpu-runner once the behaviour that flag predicates is hooked up to the "aarch64_pstate_sm_enabled" function attr.

[c-rhodes]

In lit config use absolute path to lli in llvm_tools_dir when running under emulation and no lli executable is specified. The top-level lit config adds llvm-tools-dir to PATH but this is lost when running under emulation such that previously -DARM_EMULATOR_LLI_EXECUTABLE=<path-to-llvm-tools-dir>/lli had to be specified when building. I think config.arm_emulator_lli_executable is only relevant when cross-compiling. This simplifies the flags in D148232.

[c-rhodes]

In D148111#4264730, @DavidSpickett wrote:

QEMU is now available on our AArch64 bots:

root@linaro-clang-aarch64-lld-2stage:/# qemu-aarch64 --version
qemu-aarch64 version 7.1.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

Please put up a patch for llvm-zorg to setup the bots.

Done, see D148232.

[awarzynski]

mlir/test/Integration/Dialect/SparseTensor/CPU/lit.local.cfg

23–25 ↗

(On Diff #513226)

this is lost when running under an emulator

Why and where? This feels odd - shouldn't we be fixing that instead of adding similar logic in 3 different places?

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

Hooking -force-streaming-compatible-sve into mlir-cpu-runner would also be an option, but definitely not in this patch.

10

IIUC, the only bit that makes this test require SME is this:

{passthrough = ["aarch64_pstate_sm_enabled"]}

Just checking my understanding.

[c-rhodes]

mlir/test/Integration/Dialect/SparseTensor/CPU/lit.local.cfg

23–25 ↗

(On Diff #513226)

this is lost when running under an emulator

Why and where? This feels odd - shouldn't we be fixing that instead of adding similar logic in 3 different places?

Agree the duplication isn't ideal, these configs need refactoring. When running normally I think lli is found because of this the PATH modifications here: https://github.com/llvm/llvm-project/blob/9bc5e8c87e9be8db2d65e71f90ba0ceea4b814a4/mlir/test/lit.cfg.py#L64

When running under emulation this doesn't work and using an absolute path here fixes it. I did try forwarding PATH to QEMU invocation with -E to no avail.

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

Hooking -force-streaming-compatible-sve into mlir-cpu-runner would also be an option, but definitely not in this patch.

Mirroring llc flags in mlir-cpu-runner isn't particularly ideal, be nice if there were a better way

10

IIUC, the only bit that makes this test require SME is this:

{passthrough = ["aarch64_pstate_sm_enabled"]}

Just checking my understanding.

Correct, the backend will emit smstart/smstop around calls to functions with this attribute.

[awarzynski]

LGTM, thanks for working on this!

Please wait a couple of days before merging - just in case other potential reviewers are away :) Also, I would be nice to send a short PSA about this to https://discourse.llvm.org/c/mlir/. I feel that lots of folks might be interested. Also, it's something worth celebrating 🎉 .

mlir/test/Integration/Dialect/SparseTensor/CPU/lit.local.cfg

23–25 ↗

(On Diff #513226)

Cheers for the explanation. We should probably just include lli in https://github.com/llvm/llvm-project/blob/9bc5e8c87e9be8db2d65e71f90ba0ceea4b814a4/mlir/test/lit.cfg.py#L67-L88. I feel that that would help simplify quite a few things. Another patch, another time :)

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

3

Mirroring llc flags in mlir-cpu-runner isn't particularly ideal, be nice if there were a better way

Actually, this is a global LLVM backend flag rather than something specific to llc and/or lli :) Flags like this are usually exposed in other drivers (e.g. clang and flang-new) via -mllvm. As for mlir-cpu-runner, I think that this would be no different to --mattr and --march which are also supported. In general, tools that "drive" the LLVM backend have access to these options.

[aartbik]

mlir/test/Integration/Dialect/SparseTensor/CPU/lit.local.cfg

23–25 ↗

(On Diff #513226)

Can you please add to TODO with name here. I am okay accepting this for now, but I am not too happy how complex the SparseTensor lit has become, so I would like to make sure this is truly fixed in some future... ;-)

[c-rhodes]

Add a TODO to capture refactoring

[c-rhodes]

mlir/test/Integration/Dialect/SparseTensor/CPU/lit.local.cfg

23–25 ↗

(On Diff #513226)

Can you please add to TODO with name here. I am okay accepting this for now, but I am not too happy how complex the SparseTensor lit has become, so I would like to make sure this is truly fixed in some future... ;-)

Hi Aart, I've added the TODO, are you happy with this now?

[c-rhodes]

mlir/test/Integration/Dialect/SparseTensor/CPU/lit.local.cfg

23–25 ↗

(On Diff #513226)

Can you please add to TODO with name here. I am okay accepting this for now, but I am not too happy how complex the SparseTensor lit has become, so I would like to make sure this is truly fixed in some future... ;-)

Hi Aart, I've added the TODO, are you happy with this now?

This refactoring turned out to be a lot more involved than I anticipated, but I've posted a follow up D148929 as a potential fix. Let us know what you think. Cheers.

[aartbik]

Yes, thanks for adding the TODO!

mlir/test/CMakeLists.txt

set(ARM_EMULATOR_LLI_EXECUTABLE "" CACHE STRING
       "If arch-specific Arm integration tests run emulated, use this Arm native lli.")
   set(ARM_EMULATOR_UTILS_LIB_DIR "" CACHE STRING
       "If arch-specific Arm integration tests run emulated, find Arm native utility libraries in this directory.")
   option(MLIR_RUN_AMX_TESTS "Run AMX tests.")
   option(MLIR_RUN_X86VECTOR_TESTS "Run X86Vector tests.")
   option(MLIR_RUN_CUDA_TENSOR_CORE_TESTS "Run CUDA Tensor core WMMA tests.")
   option(MLIR_RUN_CUDA_SM80_TESTS "Run CUDA A100 tests.")
   option(MLIR_RUN_ARM_SVE_TESTS "Run Arm SVE tests.")
+  option(MLIR_RUN_ARM_SME_TESTS "Run Arm SME tests.")
 
 
   # The native target may not be enabled when cross compiling, raise an error.
   if(NOT MLIR_ENABLE_EXECUTION_ENGINE)
     message(FATAL_ERROR "MLIR_INCLUDE_INTEGRATION_TESTS requires a native target")
   endif()
 
 endif()
 
 llvm_canonicalize_cmake_booleans(
   LLVM_BUILD_EXAMPLES
   MLIR_ENABLE_BINDINGS_PYTHON
   MLIR_ENABLE_CUDA_CONVERSIONS
   MLIR_ENABLE_CUDA_RUNNER
   MLIR_ENABLE_ROCM_CONVERSIONS
   MLIR_ENABLE_ROCM_RUNNER
   MLIR_ENABLE_SPIRV_CPU_RUNNER
   MLIR_ENABLE_VULKAN_RUNNER
   MLIR_INCLUDE_INTEGRATION_TESTS
   MLIR_RUN_AMX_TESTS
   MLIR_RUN_CUDA_TENSOR_CORE_TESTS
   MLIR_RUN_X86VECTOR_TESTS
   MLIR_RUN_ARM_SVE_TESTS
+  MLIR_RUN_ARM_SME_TESTS
   MLIR_RUN_CUDA_SM80_TESTS
   )
 
 configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
   ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py
   MAIN_CONFIG
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/lit.local.cfg

+import sys
+
+# ArmSME tests must be enabled via build flag.
+if not config.mlir_run_arm_sme_tests:
+    config.unsupported = True
+
+# No JIT on win32.
+if sys.platform == 'win32':
+    config.unsupported = True
+
+lli_cmd = 'lli'
+if config.arm_emulator_lli_executable:
+    lli_cmd = config.arm_emulator_lli_executable
+
+config.substitutions.append(('%mlir_native_utils_lib_dir',
+    config.arm_emulator_utils_lib_dir or config.mlir_lib_dir))
+
+if config.arm_emulator_executable:
+    # Run test in emulator (QEMU)
+    emulation_cmd = config.arm_emulator_executable
+    if config.arm_emulator_options:
+        emulation_cmd = emulation_cmd + ' ' + config.arm_emulator_options
+    emulation_cmd = emulation_cmd + ' ' + lli_cmd
+    config.substitutions.append(('%lli', emulation_cmd))
+else:
+    config.substitutions.append(('%lli', lli_cmd))

mlir/test/Integration/Dialect/Vector/CPU/ArmSME/test-ssve.mlir

+// RUN: mlir-opt %s -test-lower-to-llvm | \
+// RUN: mlir-translate -mlir-to-llvmir | \
+// RUN: %lli --march=aarch64 --mattr="+sve,+sme" \
+// RUN:      -force-streaming-compatible-sve \
+// RUN:      --entry-function=entry \
+// RUN:      --dlopen=%mlir_native_utils_lib_dir/libmlir_c_runner_utils%shlibext | \
+// RUN: FileCheck %s
+
+// NOTE: To run this test, your CPU must support SME.
+
+// VLA memcopy in streaming mode.
+func.func @streaming_kernel_copy(%src : memref<?xi64>, %dst : memref<?xi64>, %size : index) attributes {passthrough = ["aarch64_pstate_sm_enabled"]} {
+  %c0 = arith.constant 0 : index
+  %c2 = arith.constant 2 : index
+  %vscale = vector.vscale
+  %step = arith.muli %c2, %vscale : index
+  scf.for %i = %c0 to %size step %step {
+    %0 = vector.load %src[%i] : memref<?xi64>, vector<[2]xi64>
+    vector.store %0, %dst[%i] : memref<?xi64>, vector<[2]xi64>
+  }
+  return
+}
+
+func.func @entry() -> i32 {
+  %i0 = arith.constant 0: i64
+  %r0 = arith.constant 0: i32
+  %c0 = arith.constant 0: index
+  %c4 = arith.constant 4: index
+  %c32 = arith.constant 32: index
+
+  // Set up memory.
+  %a = memref.alloc()      : memref<32xi64>
+  %a_copy = memref.alloc() : memref<32xi64>
+  %a_data = arith.constant dense<[1 , 2,  3 , 4 , 5,  6,  7,  8,
+                                  9, 10, 11, 12, 13, 14, 15, 16,
+                                  17, 18, 19, 20, 21, 22, 23, 24,
+                                  25, 26, 27, 28, 29, 30, 31, 32]> : vector<32xi64>
+  vector.transfer_write %a_data, %a[%c0] : vector<32xi64>, memref<32xi64>
+
+  // Call kernel.
+  %0 = memref.cast %a : memref<32xi64> to memref<?xi64>
+  %1 = memref.cast %a_copy : memref<32xi64> to memref<?xi64>
+  call @streaming_kernel_copy(%0, %1, %c32) : (memref<?xi64>, memref<?xi64>, index) -> ()
+
+  // Print and verify.
+  //
+  // CHECK:      ( 1, 2, 3, 4 )
+  // CHECK-NEXT: ( 5, 6, 7, 8 )
+  // CHECK-NEXT: ( 9, 10, 11, 12 )
+  // CHECK-NEXT: ( 13, 14, 15, 16 )
+  // CHECK-NEXT: ( 17, 18, 19, 20 )
+  // CHECK-NEXT: ( 21, 22, 23, 24 )
+  // CHECK-NEXT: ( 25, 26, 27, 28 )
+  // CHECK-NEXT: ( 29, 30, 31, 32 )
+  scf.for %i = %c0 to %c32 step %c4 {
+    %cv = vector.transfer_read %a_copy[%i], %i0 : memref<32xi64>, vector<4xi64>
+    vector.print %cv : vector<4xi64>
+  }
+
+  // Release resources.
+  memref.dealloc %a      : memref<32xi64>
+  memref.dealloc %a_copy : memref<32xi64>
+
+  return %r0 : i32
+}

mlir/test/Target/LLVMIR/arm-ssve.mlir

+// RUN: mlir-translate -mlir-to-llvmir -split-input-file %s | FileCheck %s
+
+// Attribute to enable streaming-mode.
+
+// CHECK-LABEL: @streaming_callee
+// CHECK: #[[ATTR:[0-9]*]]
+llvm.func @streaming_callee() attributes {passthrough = ["aarch64_pstate_sm_enabled"]} {
+  llvm.return
+}
+
+// CHECK: attributes #[[ATTR]] = { "aarch64_pstate_sm_enabled" }

mlir/test/lit.site.cfg.py.in

 config.enable_rocm_runner = @MLIR_ENABLE_ROCM_RUNNER@
 config.rocm_test_chipset = "@ROCM_TEST_CHIPSET@"
 config.enable_spirv_cpu_runner = @MLIR_ENABLE_SPIRV_CPU_RUNNER@
 config.enable_vulkan_runner = @MLIR_ENABLE_VULKAN_RUNNER@
 config.enable_bindings_python = @MLIR_ENABLE_BINDINGS_PYTHON@
 config.intel_sde_executable = "@INTEL_SDE_EXECUTABLE@"
 config.mlir_run_amx_tests = @MLIR_RUN_AMX_TESTS@
 config.mlir_run_arm_sve_tests = @MLIR_RUN_ARM_SVE_TESTS@
+config.mlir_run_arm_sme_tests = @MLIR_RUN_ARM_SME_TESTS@
 config.mlir_run_x86vector_tests = @MLIR_RUN_X86VECTOR_TESTS@
 config.mlir_run_riscv_vector_tests = "@MLIR_RUN_RISCV_VECTOR_TESTS@"
 config.mlir_run_cuda_tensor_core_tests = @MLIR_RUN_CUDA_TENSOR_CORE_TESTS@
 config.mlir_run_cuda_sm80_tests = @MLIR_RUN_CUDA_SM80_TESTS@
 config.mlir_include_integration_tests = @MLIR_INCLUDE_INTEGRATION_TESTS@
 config.arm_emulator_executable = "@ARM_EMULATOR_EXECUTABLE@"
 config.arm_emulator_options = "@ARM_EMULATOR_OPTIONS@"
 config.arm_emulator_lli_executable = "@ARM_EMULATOR_LLI_EXECUTABLE@"