Skip to content

[compiler-rt][cmake] Test COMPILER_RT_HAS_AARCH64_SME with arm64 #141115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 22, 2025
+15 −2
Merged

[compiler-rt][cmake] Test COMPILER_RT_HAS_AARCH64_SME with arm64 #141115

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions compiler-rt/cmake/Modules/BuiltinTests.cmake
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,3 +134,16 @@ function(builtin_check_c_compiler_source output source)
endif()
endif()
endfunction()

function(builtin_check_c_compiler_source_with_flags output source flags)
if(NOT DEFINED ${output})
message(STATUS "Performing Test ${output}")
try_compile_only(result SOURCE ${source} FLAGS ${flags})
set(${output} ${result} CACHE INTERNAL "Compiler supports ${output} with ${flags}")
if(${result})
message(STATUS "Performing Test ${output} - Success")
else()
message(STATUS "Performing Test ${output} - Failed")
endif()
endif()
endfunction()
4 changes: 2 additions & 2 deletions compiler-rt/cmake/builtin-config-ix.cmake
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,14 +41,14 @@ asm(\".arch armv8-a+lse\");
asm(\"cas w0, w1, [x2]\");
")

builtin_check_c_compiler_source(COMPILER_RT_HAS_AARCH64_SME
builtin_check_c_compiler_source_with_flags(COMPILER_RT_HAS_AARCH64_SME
"
void foo(void) __arm_streaming_compatible {
asm(\".arch armv9-a+sme2\\n\"
\"smstart\\n\"
\"ldr zt0, [sp]\");
}
")
" "-target aarch64-linux-gnu")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we document somewhere which compilers are supported to build compiler-rt? If we support non-clang compilers, this test won't work on such compilers. (And if we don't support non-clang compilers, why are we checking this?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This SME test is to check the clang being used is new enough to support compiling the builtins for SME.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you're saying the only supported compiler is clang? What versions of clang?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea of this test is to check if the clang version is new enough in terms of features that it doesn't barf when given SME2 constructs and the keyword attributes __arm_streaming_compatible. It doesn't need to check for a specific clang version.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to hardcode versions here, but we need to have some idea, in general, of what compilers we support. Like, are we going to add code to support clang 3.0? Probably not, but have we written that down anywhere?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm understanding your point right, I think the question of what we support for compiler-rt in general is something I don't know. I can only speak for this SME feature test.

If I had to guess: the de-facto compiler we support has always been clang since the runtime was intended to be a companion, a la libgcc. It wasn't intended to always be rev-locked to a particular clang since before the monorepo transition it wasn't coupled at the svn level.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Historically, it's been possible to build compiler-rt with LLVM_ENABLE_PROJECTS, and that just picks the same host compiler you use to build LLVM itself. Which isn't necessarily clang; could be gcc, or msvc. Not sure that's something we're interested in supporting long-term, I guess, but I don't think there's anything currently preventing it. (See #124012 .)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was under the impression that LLVM_ENABLE_PROJECTS wasn't supposed to be used anymore for compiler-rt and it was only a matter of time before support is removed completely. On that basis it seems the expectation is that eventually they become rev-locked. At which point some of these tests will become redundant except for ones check a particular target has been built.

And yes, I know that's a self-incriminating statement. I believe we are trying to move to LLVM_ENABLE_RUNTIMES but software is hard.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The removal from LLVM_ENABLE_PROJECTS doesn't necessarily imply anything about the compiler; even in a "runtimes" build you can point to any compiler you want.

libcxx has a specific policy around this.


check_include_files("sys/auxv.h" COMPILER_RT_HAS_AUXV)

Expand Down
Loading