[Mlir-commits] [mlir] [mlir][ArmSME] Make use of backend function attributes for enabling ZA storage (PR #71044)

Andrzej WarzyƄski llvmlistbot at llvm.org
Mon Nov 6 01:44:42 PST 2023


================
@@ -177,6 +178,39 @@ if(LLVM_ENABLE_PIC)
     target_link_options(mlir_async_runtime PRIVATE "-Wl,-exclude-libs,ALL")
   endif()
 
+  if (MLIR_RUN_ARM_SME_TESTS)
+    if (NOT DEFINED LLVM_MAIN_SRC_DIR)
+      message(FATAL_ERROR "LLVM_MAIN_SRC_DIR must be provided to build the ArmSME runtime.")
+    endif()
+
+    if (NOT DEFINED MLIR_ARM_SME__CAN_ASSEMBLE_ARM_SME)
+      # This should work on an AArch64 host with a recent version of clang.
+      file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/has_arm_sme_check.S
+      ".arch armv9-a+sme
+      .global main
+      .type   main, %function
+      main: smstart
+      .size   main, .-main")
+      try_compile(MLIR_ARM_SME__CAN_ASSEMBLE_ARM_SME ${CMAKE_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR}/has_arm_sme_check.S)
+    endif()
+
+    if (NOT MLIR_ARM_SME__CAN_ASSEMBLE_ARM_SME)
+      message(FATAL_ERROR "Host compiler must be able to assemble AArch64 SME instructions to build the ArmSME runtime.")
+    endif()
+
+    # FIXME: This is very far from ideal, but enabling compiler-rt in the main
----------------
banach-space wrote:

> Options 1 and 3 may require updating existing build to update host toolchain if current doesn't support SME. 

IIUC, all options will require a "recent" toolchain, right?

My view is that:
* Option 1 would be the cleanest/simplest and would work fine for pre-commit/post-commit testing (as Buildbots tend to build everything anyway). However, this would be too painful for developers.
* Option 2 would force us to use 2-stage builds for testing. This would be more work for developers and potentially extra set-up for buildbots.
* Options 3 is the simplest from the developer's perspective. And that's what I'd personally optimise for. I do wonder though - wouldn't it be possible to add this target in `compiler-rt` instead?

https://github.com/llvm/llvm-project/pull/71044


More information about the Mlir-commits mailing list