PKGBUILD: add "clang" mode and rename _use_llvm_lto to _use_llvm - #739
PKGBUILD: add "clang" mode and rename _use_llvm_lto to _use_llvm#739ptr1337 wants to merge 7 commits into
Conversation
| return $? | ||
| } | ||
|
|
||
| _is_clang_build() { |
There was a problem hiding this comment.
Mainly added this for the QR Code check
There was a problem hiding this comment.
Pull request overview
This PR updates the linux-cachyos PKGBUILD to support building with Clang while keeping LTO disabled, by renaming the existing LLVM/LTO selector and expanding it with a new clang mode.
Changes:
- Rename
_use_llvm_ltoto_use_llvmand broaden its accepted values to includeclang. - Add
_is_clang_build()helper and update suffix/makedepends logic to treatclanglike other LLVM-based builds. - Update build/config/signing/header dependency logic to use the new
_use_llvmvariable and clang-build detection.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1Naim
left a comment
1Naim
left a comment
There was a problem hiding this comment.
Some comments, I think we should keep _use_llvm_lto as a compat option for something like the kernel manager.
| [[ "$_use_llvm" = "thin" || "$_use_llvm" = "full" || "$_use_llvm" = "thin-dist" ]] | ||
| return $? | ||
| } | ||
|
|
||
| _is_clang_build() { | ||
| _is_lto_kernel || [[ "$_use_llvm" = "clang" ]] |
There was a problem hiding this comment.
| [[ "$_use_llvm" = "thin" || "$_use_llvm" = "full" || "$_use_llvm" = "thin-dist" ]] | |
| return $? | |
| } | |
| _is_clang_build() { | |
| _is_lto_kernel || [[ "$_use_llvm" = "clang" ]] | |
| _is_clang_build() { | |
| [[ "$_use_llvm" != "none" ]] | |
| } | |
| is_lto_kernel { | |
| is_clang_build && [[ "$_use_llvm" != "clang" ]] | |
| } |
Just a slight nitpick. Either works.
There was a problem hiding this comment.
I don't think we should make it like that, since we don't validate user input, so it will be true even if there an invalid value.
| # "thin": use Clang with ThinLTO - multiple threads, faster and uses less memory, may have a lower runtime performance than Full. | ||
| # "thin-dist": use Clang with distributed ThinLTO - https://discourse.llvm.org/t/rfc-distributed-thinlto-build-for-kernel/85934 | ||
| # "full": use Clang with Full LTO - 1 thread for Linking, slow and uses more memory, theoretically with the highest performance gains. | ||
| : "${_use_llvm:=thin}" |
There was a problem hiding this comment.
Would it make sense to replace "none" and "clang" to "no" and "yes" respectively to match the other config options?
There was a problem hiding this comment.
This would require then another variable for clang = no/yes and then which kind of lto mode?
There was a problem hiding this comment.
No just keep it all-in-one.
So instead of none, clang, thin, full, etc. There's no, yes, thin, full, etc.
|
Happy in the discord made some benchmarks with "CachyMod". Generally we can see there:
This reflects my expections. The difference, outside in the blender benchmark compared to ThinLTO seems ok. So, in case we will ever need Rust support this could be done with disabling ThinLTO 
|
|
Yes This |
|
@1Naim I think we should proceed with this for 7.2 eventually? |
yeah, i agree |
Add a new "clang" option to _use_llvm (formerly _use_llvm_lto) that uses Clang as the compiler with LTO disabled. This is useful for AutoFDO/Propeller profiling workflows and testing without the overhead of LTO linking. Signed-off-by: Peter Jung <admin@ptr1337.dev>
Signed-off-by: Peter Jung <admin@ptr1337.dev>
Signed-off-by: Peter Jung <admin@ptr1337.dev>
Signed-off-by: Peter Jung <admin@ptr1337.dev>
Signed-off-by: Peter Jung <admin@ptr1337.dev>
Signed-off-by: Peter Jung <admin@ptr1337.dev>
|
All ready to review. PKGBUILDs are synced, default kernel uses now "Clang". I gonna write tomorrow to Google and ask what their plans are to support Rust + ThinLTO in the near future. Scripts have been updated too. We should merge this for 7.2 release then. I think we could theortically exclude the LTS kernel ,but well |
|
Could we maybe land #944 first, and then rebase this over it? |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.
Suppressed comments (1)
linux-cachyos/PKGBUILD:96
- The repository build workflow still exports
_use_llvm_lto(.github/workflows/build.yml:64). After this rename that value is ignored, so both thegccandclangmatrix jobs use this newclangdefault and GCC is no longer tested. Update the workflow to export_use_llvm(mappinggcctononeandclangto the intended Clang mode) as part of this PR.
: "${_use_llvm:=clang}"
Add a new "clang" option to _use_llvm (formerly _use_llvm_lto) that uses Clang as the compiler with LTO disabled. This is useful for AutoFDO/Propeller profiling workflows and testing without the overhead of LTO linking.
I will run some benchmarks to test the performance between ThinLTO + Propeller and Clang + Propeller. The main benefit we would have here, is that we can enable support for Rust and preparing for the future in case more and more drivers get depending on it.
The QR_CODE Bluescreen is pretty nice and we can also implement an own site for this.
Will enhance to other PKGBUILDs when reviewed