wip: build: add support for llvm clang#10759
Conversation
lgirdwood
changed the title
There was a problem hiding this comment.
This script was far too long from the beginning. I wonder if it would be possible to move some of the things it's doing directly to west. Perfect solution would be setting some environments and calling west in workflow.
Soon it will be a wrapper on west having over 2K lines of code. My local script has 250 with comments :)
There was a problem hiding this comment.
the script has a lot of convenience - 2k lines is not a problem, especially today.
|
@lgirdwood I take your patches and can build LLVM. I also build SOF with it and it looks OK. I run in qemu and see lots of code being run to idle. I think this looks OK but not expert on SOF. I am working on some LLVM updates for fun that I will send. Thank you. |
|
@lgirdwood I made 2 PRs last night for HIFI and FLIX , please check lgirdwood/llvm-project#1 |
@hliao8 PRs look OK, let me try on my devices and qemu and get back to you. |
Ok, merged, can build and boot FW, load topologies but something wrong at trigger(). Its definitely in the right direction. I'll take a look at trigger when time permits. |
@lgirdwood I saw you made some fixes I am sorry for the bugs. I also had 2 of those fixes and have another fix for you to try lgirdwood/llvm-project#2 |
@hliao8 sorry for delay, after testing with your latest update I can play audio. I've merged it to my branch and will give it more testing. Please dont upstream yet, I would like to test some more and I would have to upstream my base level patches before you upstream your SIMD/FLIX patches. I think its probably safe to give it a few more weeks testing. |
|
@lgirdwood I have made some fixes here. Can you test them. lgirdwood/llvm-project#3 |
@hliao8 thanks, merged and the audio noise issue is gone when I tested on my device, but I think this needs more testing in general due to the nature of the work before upstreaming. There are lots of modules that can run on TGL DSP, I would make sure that they all work as expected as this will give your code more test coverage. |
Add support for building SOF firmware with the upstream LLVM/Clang toolchain via a new --llvm-clang option: - Add the --llvm-clang option pointing at an LLVM/Clang build - Select the Zephyr "llvm" toolchain variant for Clang builds - Auto-detect the Zephyr SDK install dir for the LLVM variant - Map NVL to intel_ace40 for the LLVM build Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
- llext_link_helper.py: Treat .rodata as readonly even when marked writable by the Clang/objcopy LLEXT pipeline, and place readonly sections BEFORE .text so Xtensa l32r instructions (which can only reach backwards up to 256KB) can access .rodata literals. - zephyr/CMakeLists.txt: Make -mtext-section-literals conditional via check_c_compiler_flag (Clang doesn't support it), and force the Zephyr SDK GCC linker for the LLEXT shared library link step. Use the ZEPHYR_SDK_INSTALL_DIR CMake cache variable (instead of the environment variable) to locate the SDK GCC, so the build script can pass the SDK path reliably. Signed-off-by: Liam Girdwood <liam.r.girdwood@intel.com>
Provide a no-op llext_manager_rm_domain() macro in the non-LLEXT path to match the available API. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
When building with upstream LLVM targeting Xtensa, the build system defines both __XCC_CLANG__ and __XCC__. The old order checked __XCC__ first, so the Cadence XCC block was entered and tried to include <xtensa/hal.h> which is not available in the LLVM SDK. Reorder the guards so __XCC_CLANG__ is checked first, and add a plain __clang__ fallback for any other Clang-based Xtensa toolchain. The resulting CC_NAME/CC_MAJOR/CC_MINOR/CC_MICRO macros are used by base_fw.c to report compiler identity over IPC4. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Use <xtensa/config/core-isa.h> consistently in HiFi FIR/SRC/ARIA and format headers instead of <xtensa/config/defs.h>. This avoids compiler-specific include probing and keeps build behavior identical across Cadence and upstream LLVM toolchains, since Zephyr SDK provides core-isa headers consistently for Xtensa targets.
lgirdwood
force-pushed
the
clang-upstream
branch
from
c159128 to
9e89986
Compare
|
@hliao8 see above, I've cleaned up the llvm headers so there is not need to do anything special for each compiler. |
4 participants
Just a heads up for anyone interested in llvm clang support to build SOF xtensa targets. Its still very early WIP with lots of work still to do but end result should be a single xtensa clang compiler for all SOF targets for CI, twister etc. Opens door to other non C based languages long term.
Needs zephyrproject-rtos/zephyr#108765
and
llvm/llvm-project@main...lgirdwood:llvm-project:upstream/dev