Any "real" advantages over MLFS?

[firasuke]

As the title states, are there any real advantages to CMLFS over MLFS other than that the toolchain is a bit more bloated now as it uses both LLVM/GCC, and that LLVM is a bit worse at optimizations?

[dslm4515]

That's a good question. Short answer: No... as in no performance increase [so far].

I did do a little research (before I started this project) to see if LLVM provided better optimizations than GCC: From what I found, not much and if so, very little... probably like 3-5% difference?

CMLFS would not need GCC if it were not for elfutils requiring GCC (clang has pseudo support for GNU99, but apparently not good enough for elfutils). Grub builds a malformed img file if clang is used instead of GCC. I figured, i'll add GCC so that CMLFS can compile anything MLFS can. I suppose CMLFS might be handy for someone looking to build a non-GNU system ... just to not have GCC.

In fact, I find it harder to build LLVM as part of a standalone (sand boxed) toolchain and build LLVM again with that toolchain. I do agree, LLVM is quite bloated: LLVM has more tools beyond binary tools and C/C++ compilers. I couldnt find a way to strip LLVM or find a fork of it. It was harder to configure than GCC. For GCC, i just had to modify a few files and a GCC specs file. LLVM made it harder, and worse if what I was looking for was not really documented well (I still have no idea how to configure clang with a .cfg file)

I am currently building B[C]MLFS to see how stable CMLFS is and see if there are any perks over MLFS.

[firasuke]

Good luck with your endeavors!

[dslm4515]

I also forgot: GCC does take less time to build compared to LLVM...most likely due to the extra tools in LLVM.

GCC = ~30min LLVM( amdgpu,X86,BPF) = ~206min

Supposedly, LLVM's LLD links faster than GNU's Gold LD... which won't matter for running a system.

I guess in the end, CMLFS may be handy for hardware not supported by GCC but supported by LLVM? ... which is very unlikely, i think.

As a side note, LLVM has risc-v arch support since 9.0 but GCC's support is still WIP... I would love to build on risc-v, but ... a decent risc-v motherboard is way out of my budget.

[firasuke]

GCC = ~30min LLVM( amdgpu,X86,BPF) = ~206min

Wow, I didn't expect the difference in build time would be so significant. Thanks for reporting your trials!

Supposedly, LLVM's LLD links faster than GNU's Gold LD... which won't matter for running a system.

That (and not needing binutils in your typical LLVM toolchain, in addition to the license) are the only reasons I can think of for choosing an LLVM toolchain over a GCC one.

I guess in the end, CMLFS may be handy for hardware not supported by GCC but supported by LLVM? ... which is very unlikely, i think.

True. GCC is still better (and faster) at optimizing most packages (when using musl libc, especially for size optimizations).

It's definitely an interesting approach to an LFS-like system, and comparing both MLFS and CMLFS would, most certainly, be very beneficial (specifically in terms of optimizations).

Either way, keep up the great work, and always report your much appreciated findings!

[dslm4515]

Another note, not all source code can be compiler-unbiased, unfortunately. Some packages require 'GCC macros' and other GCC specific features. It reminds me of how a lot of software still depends on XFree86/Xorg... such as FireFox (Still can't get a pure wayland-musl build to work). I don't think there will ever be a time where LLVM can be a drop in replacement for GCC.

I was under the impression that libc++ was more standardized than libstdc++... kind of like how Musl libc is more standardized that glibc (avoids using hacks to fix issues). But i think that may not be true. If i remember correctly libc++ isn't as complete as libstdc++. In this sense, LLVM should really stay as an auxillary/secondary toolchain with GCC as main/primary.

[firasuke]

Another note, not all source code can be compiler-unbiased, unfortunately. Some packages require 'GCC macros' and other GCC specific features. It reminds me of how a lot of software still depends on XFree86/Xorg... such as FireFox (Still can't get a pure wayland-musl build to work). I don't think there will ever be a time where LLVM can be a drop in replacement for GCC.

Exactly, many software still expect GCC.

I was under the impression that libc++ was more standardized than libstdc++... kind of like how Musl libc is more standardized that glibc (avoids using hacks to fix issues). But i think that may not be true. If i remember correctly libc++ isn't as complete as libstdc++. In this sense, LLVM should really stay as an auxillary/secondary toolchain with GCC as main/primary.

That, and to this day libc++ still has regressions when compared to libstdc++, also LLVM and musl don't blend well last time I checked.

[dslm4515]

I am currently exploring LTO (Link-Time-Optimization). It sounds like trading longer compile times for hopefully faster execution times and maybe smaller binaries/libraries.

I have a CMLFS build with no LTO and I am working on another build with LTO (using the same sources). A lot of documentation I find refers to older LLVM, like LLVM-6.0.0 or LLVM-8.00. So am not sure if methods to implement LTO with clang/LLVM has changed in LLVM-12.

So far it sounds like by default, LLVM supports LTO and it can be used by setting CFLAGS="-flto" CXXFLAGS="-flto". I am still looking for guides as I see options like -flto=thin. Binutils & GCC in CMLFS already has LTO support.

Once I finish a build of CMLFS-LTO, i will compare it to the non-LTO build

[owl4ce]

I am currently exploring LTO (Link-Time-Optimization). It sounds like trading longer compile times for hopefully faster execution times and maybe smaller binaries/libraries.

I have a CMLFS build with no LTO and I am working on another build with LTO (using the same sources). A lot of documentation I find refers to older LLVM, like LLVM-6.0.0 or LLVM-8.00. So am not sure if methods to implement LTO with clang/LLVM has changed in LLVM-12.

So far it sounds like by default, LLVM supports LTO and it can be used by setting CFLAGS="-flto" CXXFLAGS="-flto". I am still looking for guides as I see options like -flto=thin. Binutils & GCC in CMLFS already has LTO support.

Once I finish a build of CMLFS-LTO, i will compare it to the non-LTO build

And remember that not all packages support LTO.

[owl4ce]

You may want to use -march=<arch> (prefer with native) as well. Also I recommend to use -pipe flag to C and CXX flags.

[owl4ce]

And also optimization level 3 (and higher) is not always profitable, I'm even more interested with -Oz.

[dslm4515]

You may want to use -march=<arch> as well. Also I recommend to use -pipe flag to C and CXX flags.

I do use a patch from graysk2 to "add additional optimization/tuning for kernel builds by adding more micro-architectures options"... of course, thats juke the kernel and not the rest of the userland

[owl4ce]

@dslm4515 You may want to enable GitHub discussion in the repo's settings.

[dslm4515]

Done.

I don't remember seeing 'Discussions' when i created this repo

[dslm4515]

And also optimization level 3 (and higher) is not always profitable, I'm even more interested with -Oz.

-Oz ? Can't seem to find any info on that

[owl4ce]

And also optimization level 3 (and higher) is not always profitable, I'm even more interested with -Oz.

-Oz ? Can't seem to find any info on that

It's clang specific. https://clang.llvm.org/docs/CommandGuide/clang.html