Skip to content

[libclc] Pass -fapprox-func when compiling 'native' builtins #133119

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.

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 4 commits into from
Mar 28, 2025

Conversation

frasercrmck
Copy link
Contributor

The libclc build system isn't well set up to pass arbitrary options to arbitrary source files in a non-intrusive way. There isn't currently any other motivating example to warrant rewriting the build system just to satisfy this requirement. So this commit uses a filename-based approach to inserting this option into the list of compile flags.

@frasercrmck frasercrmck added the libclc libclc OpenCL library label Mar 26, 2025
@frasercrmck frasercrmck requested a review from arsenm March 26, 2025 16:36
@arsenm
Copy link
Contributor

arsenm commented Mar 27, 2025

Cmake already lets you do this:

set_source_files_properties(
  ${CMAKE_CURRENT_SOURCE_DIR}/native.cl
  PROPERTIES COMPILE_FLAGS "-fapprox-func")

The libclc build system isn't well set up to pass arbitrary options to
arbitrary source files in a non-intrusive way. There isn't currently any
other motivating example to warrant rewriting the build system just to
satisfy this requirement. So this commit uses a filename-based approach
to inserting this option into the list of compile flags.
@frasercrmck
Copy link
Contributor Author

set_source_files_properties

That's true but since we're compiling with custom commands (I think) the properties won't automatically get picked up.

That said, we could perhaps set the properties as you suggest and retrieve them with get_source_file_property. We'd still need to set the properties "explicitly" as the SOURCES system isn't well set up to add arbitrary (lists of) stuff on top of the file name. But at least we could do it in the top-level CMakeLists which feels less hacky to me.

I'll play around with it.

@frasercrmck frasercrmck force-pushed the libclc-approx-native-funcs branch from 7bea963 to 2199b0e Compare March 27, 2025 10:29
@frasercrmck
Copy link
Contributor Author

I've pushed an update with uses the COMPILE_OPTIONS property. It's definitely better, thanks for the suggestion.

It would be best if there were CMakeLists.txt in each sub-directory which added the properties. However, because we currently have this system where targets include from multiple directories (e.g., r600 includes stuff from r600/, amdgpu/ and generic/), and you can only add_subdirectory once, it gets a bit complicated. We'd have to ensure that generic is only included once, but that would also mean that it would be harder to do target-specific things in there. It might be possible (I think you can set a custom (target-specific?) build directory in add_subdirectory), but for now I'm just setting the properties in the top-level CMakeLists.txt. I'd be a bit nervous of rewriting the build system at this time.

@arsenm arsenm added the cmake Build system in general and CMake in particular label Mar 28, 2025
@frasercrmck frasercrmck merged commit 0a74cbf into llvm:main Mar 28, 2025
12 checks passed
@frasercrmck frasercrmck deleted the libclc-approx-native-funcs branch March 28, 2025 08:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake Build system in general and CMake in particular libclc libclc OpenCL library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants