[PATCH] clang: use Release instead of MinSizeRel

[PATCH] clang: use Release instead of MinSizeRel

[martin.jansa]

From: Martin Jansa <martin.jansa@gmail.com>

It was changed in:
https://git.openembedded.org/openembedded-core/commit/?id=ea9b33f7c12f773830ec860ae817a3ed1368612b
to save the disk space, but the build time impact is significant.

Both llvm and clang recipes are now using MinSizeRel, but the build time
impact is significant mostly from clang recipes and also the disk space
is affected more by llvm, than clang. So change the default only for
clang recipe. In theory we could use Release only for clang-native and
leave MinSizeRel for target clang (assuming that most people don't do
many demanding builds on target, but that won't be true for something
like build appliance built with OE).

chromium-x11.do_compile time with 64 thread AMD Threadripper 3970x
increased by 80% from 6930s to 12300s, measured in wrynose release.

With current master chromium-x11.do_compile time is also around 80%
slower compared to both using Release or 66.6% slower compared to
clang using Release:

MinSizeRel in both clang and llvm:
20.09user 2.56system 3:05:09elapsed 0%CPU (0avgtext+0avgdata 58500maxresident)k

MinSizeRel in llvm, Release in clang:
18.82user 2.61system 1:51:40elapsed 0%CPU (0avgtext+0avgdata 58776maxresident)k

Release in both clang and llvm:
18.83user 2.59system 1:45:32elapsed 0%CPU (0avgtext+0avgdata 59424maxresident)k

sstate-cache size after building core-image-sato with
PREFERRED_TOOLCHAIN_TARGET = "clang"
and target clang included as well as chromium-x11 in the image:

increased by less than 2% (137MB):
8988    sstate-cache-MinSizeRel-both
9125    sstate-cache-Release-both

populate_sysroot:
llvm:         14M: 175M -> 189M
llvm-native:  29M:  98M -> 127M
clang:         4M:  82M ->  86M
clang-native: 30M: 102M -> 132M

llvm package: 26M: 314M -> 340M
llvm ipk:     27M: 353M -> 380M

clang package: 3M:  89M ->  92M
clang ipk:     4M: 100M -> 104M

ipk package sizes:
7.0M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-bin_23.1.3-r0.3_x86-64-v3.ipk
87M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-dbg_23.1.3-r0.3_x86-64-v3.ipk
6.5M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-dev_23.1.3-r0.3_x86-64-v3.ipk
66M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-src_23.1.3-r0.3_x86-64-v3.ipk
153M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-staticdev_23.1.3-r0.3_x86-64-v3.ipk
35M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm_23.1.3-r0.3_x86-64-v3.ipk

8.3M    tmp-Release/deploy/ipk/x86-64-v3/llvm-bin_23.1.3-r0.2_x86-64-v3.ipk
98M     tmp-Release/deploy/ipk/x86-64-v3/llvm-dbg_23.1.3-r0.2_x86-64-v3.ipk
6.5M    tmp-Release/deploy/ipk/x86-64-v3/llvm-dev_23.1.3-r0.2_x86-64-v3.ipk
66M     tmp-Release/deploy/ipk/x86-64-v3/llvm-src_23.1.3-r0.2_x86-64-v3.ipk
164M    tmp-Release/deploy/ipk/x86-64-v3/llvm-staticdev_23.1.3-r0.2_x86-64-v3.ipk
41M     tmp-Release/deploy/ipk/x86-64-v3/llvm_23.1.3-r0.2_x86-64-v3.ipk

8.8M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-dbg_23.1.3-r0.3_x86-64-v3.ipk
4.3M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-dev_23.1.3-r0.3_x86-64-v3.ipk
20K     tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-doc_23.1.3-r0.3_x86-64-v3.ipk
48K     tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-format_23.1.3-r0.3_x86-64-v3.ipk
40K     tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-libclang-python_23.1.3-r0.3_x86-64-v3.ipk
48M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-staticdev_23.1.3-r0.3_x86-64-v3.ipk
2.9M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-tidy_23.1.3-r0.3_x86-64-v3.ipk
1.3M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-tools_23.1.3-r0.3_x86-64-v3.ipk
6.1M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang_23.1.3-r0.3_x86-64-v3.ipk
18M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/libclang-cpp23.1_23.1.3-r0.3_x86-64-v3.ipk
11M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/libclang23.1_23.1.3-r0.3_x86-64-v3.ipk

7.8M    tmp-Release/deploy/ipk/x86-64-v3/clang-dbg_23.1.3-r0.4_x86-64-v3.ipk
4.3M    tmp-Release/deploy/ipk/x86-64-v3/clang-dev_23.1.3-r0.4_x86-64-v3.ipk
20K     tmp-Release/deploy/ipk/x86-64-v3/clang-doc_23.1.3-r0.4_x86-64-v3.ipk
52K     tmp-Release/deploy/ipk/x86-64-v3/clang-format_23.1.3-r0.4_x86-64-v3.ipk
40K     tmp-Release/deploy/ipk/x86-64-v3/clang-libclang-python_23.1.3-r0.4_x86-64-v3.ipk
47M     tmp-Release/deploy/ipk/x86-64-v3/clang-staticdev_23.1.3-r0.4_x86-64-v3.ipk
3.3M    tmp-Release/deploy/ipk/x86-64-v3/clang-tidy_23.1.3-r0.4_x86-64-v3.ipk
1.4M    tmp-Release/deploy/ipk/x86-64-v3/clang-tools_23.1.3-r0.4_x86-64-v3.ipk
6.8M    tmp-Release/deploy/ipk/x86-64-v3/clang_23.1.3-r0.4_x86-64-v3.ipk
21M     tmp-Release/deploy/ipk/x86-64-v3/libclang-cpp23.1_23.1.3-r0.4_x86-64-v3.ipk
13M     tmp-Release/deploy/ipk/x86-64-v3/libclang23.1_23.1.3-r0.4_x86-64-v3.ipk

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
---
 meta/recipes-devtools/clang/clang_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/clang/clang_git.bb b/meta/recipes-devtools/clang/clang_git.bb
index 3b93f0d02c..90076f9d6d 100644
--- a/meta/recipes-devtools/clang/clang_git.bb
+++ b/meta/recipes-devtools/clang/clang_git.bb
@@ -60,7 +60,7 @@ EXTRA_OECMAKE += "-DLLVM_ENABLE_ASSERTIONS=OFF \
                   -DFFI_INCLUDE_DIR=$(pkg-config --variable=includedir libffi) \
                   -DLLVM_BUILD_EXTERNAL_COMPILER_RT=ON \
                   -DCMAKE_SYSTEM_NAME=Linux \
-                  -DCMAKE_BUILD_TYPE=MinSizeRel \
+                  -DCMAKE_BUILD_TYPE=Release \
                   -DLLVM_VERSION_SUFFIX='${VER_SUFFIX}' \
                   -DLLVM_CMAKE_DIR=${STAGING_LIBDIR}/cmake/llvm \
                   -DLLVM_NATIVE_TOOL_DIR=${STAGING_BINDIR_NATIVE} \

Re: [PATCH] clang: use Release instead of MinSizeRel

[mark.yang]

[-- Attachment #1: Type: text/plain, Size: 101 bytes --]

Thank you, Martin.
What do you think about changing this to release only for native and nativesdk?

[-- Attachment #2: Type: text/html, Size: 116 bytes --]

Re: [OE-core] [PATCH] clang: use Release instead of MinSizeRel

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 7128 bytes --]

On Mon, Oct 19, 2026 at 4:25 AM Martin Jansa via lists.openembedded.org
<martin.jansa=gmail.com@lists.openembedded.org> wrote:

> From: Martin Jansa <martin.jansa@gmail.com>
>
> It was changed in:
>
> https://git.openembedded.org/openembedded-core/commit/?id=ea9b33f7c12f773830ec860ae817a3ed1368612b
> to save the disk space, but the build time impact is significant.
>
> Both llvm and clang recipes are now using MinSizeRel, but the build time
> impact is significant mostly from clang recipes and also the disk space
> is affected more by llvm, than clang. So change the default only for
> clang recipe. In theory we could use Release only for clang-native and
> leave MinSizeRel for target clang (assuming that most people don't do
> many demanding builds on target, but that won't be true for something
> like build appliance built with OE).
>
> chromium-x11.do_compile time with 64 thread AMD Threadripper 3970x
> increased by 80% from 6930s to 12300s, measured in wrynose release.
>
> With current master chromium-x11.do_compile time is also around 80%
> slower compared to both using Release or 66.6% slower compared to
> clang using Release:
>
> MinSizeRel in both clang and llvm:
> 20.09user 2.56system 3:05:09elapsed 0%CPU (0avgtext+0avgdata
> 58500maxresident)k
>
> MinSizeRel in llvm, Release in clang:
> 18.82user 2.61system 1:51:40elapsed 0%CPU (0avgtext+0avgdata
> 58776maxresident)k
>
> Release in both clang and llvm:
> 18.83user 2.59system 1:45:32elapsed 0%CPU (0avgtext+0avgdata
> 59424maxresident)k
>
> sstate-cache size after building core-image-sato with
> PREFERRED_TOOLCHAIN_TARGET = "clang"
> and target clang included as well as chromium-x11 in the image:
>
> increased by less than 2% (137MB):
> 8988    sstate-cache-MinSizeRel-both
> 9125    sstate-cache-Release-both
>
> populate_sysroot:
> llvm:         14M: 175M -> 189M
> llvm-native:  29M:  98M -> 127M
> clang:         4M:  82M ->  86M
> clang-native: 30M: 102M -> 132M
>
> llvm package: 26M: 314M -> 340M
> llvm ipk:     27M: 353M -> 380M
>
> clang package: 3M:  89M ->  92M
> clang ipk:     4M: 100M -> 104M
>
> ipk package sizes:
> 7.0M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-bin_23.1.3-r0.3_x86-64-v3.ipk
> 87M
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-dbg_23.1.3-r0.3_x86-64-v3.ipk
> 6.5M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-dev_23.1.3-r0.3_x86-64-v3.ipk
> 66M
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-src_23.1.3-r0.3_x86-64-v3.ipk
> 153M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm-staticdev_23.1.3-r0.3_x86-64-v3.ipk
> 35M     tmp-MinSizeRel/deploy/ipk/x86-64-v3/llvm_23.1.3-r0.3_x86-64-v3.ipk
>
> 8.3M    tmp-Release/deploy/ipk/x86-64-v3/llvm-bin_23.1.3-r0.2_x86-64-v3.ipk
> 98M     tmp-Release/deploy/ipk/x86-64-v3/llvm-dbg_23.1.3-r0.2_x86-64-v3.ipk
> 6.5M    tmp-Release/deploy/ipk/x86-64-v3/llvm-dev_23.1.3-r0.2_x86-64-v3.ipk
> 66M     tmp-Release/deploy/ipk/x86-64-v3/llvm-src_23.1.3-r0.2_x86-64-v3.ipk
> 164M
> tmp-Release/deploy/ipk/x86-64-v3/llvm-staticdev_23.1.3-r0.2_x86-64-v3.ipk
> 41M     tmp-Release/deploy/ipk/x86-64-v3/llvm_23.1.3-r0.2_x86-64-v3.ipk
>
> 8.8M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-dbg_23.1.3-r0.3_x86-64-v3.ipk
> 4.3M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-dev_23.1.3-r0.3_x86-64-v3.ipk
> 20K
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-doc_23.1.3-r0.3_x86-64-v3.ipk
> 48K
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-format_23.1.3-r0.3_x86-64-v3.ipk
> 40K
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-libclang-python_23.1.3-r0.3_x86-64-v3.ipk
> 48M
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-staticdev_23.1.3-r0.3_x86-64-v3.ipk
> 2.9M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-tidy_23.1.3-r0.3_x86-64-v3.ipk
> 1.3M
> tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang-tools_23.1.3-r0.3_x86-64-v3.ipk
> 6.1M    tmp-MinSizeRel/deploy/ipk/x86-64-v3/clang_23.1.3-r0.3_x86-64-v3.ipk
> 18M
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/libclang-cpp23.1_23.1.3-r0.3_x86-64-v3.ipk
> 11M
>  tmp-MinSizeRel/deploy/ipk/x86-64-v3/libclang23.1_23.1.3-r0.3_x86-64-v3.ipk
>
> 7.8M
> tmp-Release/deploy/ipk/x86-64-v3/clang-dbg_23.1.3-r0.4_x86-64-v3.ipk
> 4.3M
> tmp-Release/deploy/ipk/x86-64-v3/clang-dev_23.1.3-r0.4_x86-64-v3.ipk
> 20K
>  tmp-Release/deploy/ipk/x86-64-v3/clang-doc_23.1.3-r0.4_x86-64-v3.ipk
> 52K
>  tmp-Release/deploy/ipk/x86-64-v3/clang-format_23.1.3-r0.4_x86-64-v3.ipk
> 40K
>  tmp-Release/deploy/ipk/x86-64-v3/clang-libclang-python_23.1.3-r0.4_x86-64-v3.ipk
> 47M
>  tmp-Release/deploy/ipk/x86-64-v3/clang-staticdev_23.1.3-r0.4_x86-64-v3.ipk
> 3.3M
> tmp-Release/deploy/ipk/x86-64-v3/clang-tidy_23.1.3-r0.4_x86-64-v3.ipk
> 1.4M
> tmp-Release/deploy/ipk/x86-64-v3/clang-tools_23.1.3-r0.4_x86-64-v3.ipk
> 6.8M    tmp-Release/deploy/ipk/x86-64-v3/clang_23.1.3-r0.4_x86-64-v3.ipk
> 21M
>  tmp-Release/deploy/ipk/x86-64-v3/libclang-cpp23.1_23.1.3-r0.4_x86-64-v3.ipk
> 13M
>  tmp-Release/deploy/ipk/x86-64-v3/libclang23.1_23.1.3-r0.4_x86-64-v3.ipk
>
>
I expected some impact on clang's performance and the changes were
targeted more at clang as
embedded library for other packages like mesa but this meant that clang as
a static compiler would
take the hit and its evident from numbers you published, so distos and
recipes with TOOLCHAIN = "clang"
 are most impacted. I also wonder if we use different opt levels for clang
and llvm then are we
going into new combination thats least tested in clang/llvm community but
leaving that concern aside
I think this change is good, I would have asked to make it a packageconfig
but since there are packages
like chromium which enforce clang, we will not benefit as much

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
> ---
>  meta/recipes-devtools/clang/clang_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/clang/clang_git.bb
> b/meta/recipes-devtools/clang/clang_git.bb
> index 3b93f0d02c..90076f9d6d 100644
> --- a/meta/recipes-devtools/clang/clang_git.bb
> +++ b/meta/recipes-devtools/clang/clang_git.bb
> @@ -60,7 +60,7 @@ EXTRA_OECMAKE += "-DLLVM_ENABLE_ASSERTIONS=OFF \
>                    -DFFI_INCLUDE_DIR=$(pkg-config --variable=includedir
> libffi) \
>                    -DLLVM_BUILD_EXTERNAL_COMPILER_RT=ON \
>                    -DCMAKE_SYSTEM_NAME=Linux \
> -                  -DCMAKE_BUILD_TYPE=MinSizeRel \
> +                  -DCMAKE_BUILD_TYPE=Release \
>                    -DLLVM_VERSION_SUFFIX='${VER_SUFFIX}' \
>                    -DLLVM_CMAKE_DIR=${STAGING_LIBDIR}/cmake/llvm \
>                    -DLLVM_NATIVE_TOOL_DIR=${STAGING_BINDIR_NATIVE} \
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#248158):
> https://lists.openembedded.org/g/openembedded-core/message/248158
> Mute This Topic: https://lists.openembedded.org/mt/121829223/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 9288 bytes --]

Re: [OE-core] [PATCH] clang: use Release instead of MinSizeRel

[Martin Jansa]

On Tue, Oct 20, 2026 at 3:12 AM mark.yang via lists.openembedded.org
<mark.yang=lge.com@lists.openembedded.org> wrote:
>
> Thank you, Martin.
> What do you think about changing this to release only for native and nativesdk?

I didn't measure the performance of clang in the target, but the disk
size impact there is even smaller than for clang-native (just 4MB for
target compared to 30M for native - not sure why), but some people
might be using target clang for doing the builds as well, that's why
in commit message I've mentioned:

In theory we could use Release only for clang-native and
leave MinSizeRel for target clang (assuming that most people don't do
many demanding builds on target, but that won't be true for something
like build appliance built with OE).

Cheers,