On Wed, Apr 14, 2021 at 5:43 PM Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers > <ndesaulniers@xxxxxxxxxx> wrote: > > > > -Oz in clang typically generates larger kernel code than -Os; LLVM > > seems to aggressively emit libcalls even when the setup for a call > > would be larger than the inlined call itself. Is z smaller than s for > > the existing rust examples? > > I will check if the `s`/`z` flags have the exact same semantics as > they do in Clang, but as a quick test (quite late here, sorry!), yes, > it seems `z` is smaller: > > text data bss dec hex filename > > 126568 8 104 126680 1eed8 drivers/android/rust_binder.o [s] > 122923 8 104 123035 1e09b drivers/android/rust_binder.o [z] > > 212351 0 0 212351 33d7f rust/core.o [s] > 207653 0 0 207653 32b25 rust/core.o [z] cool, thanks for verifying. LGTM > > This is a mess; who thought it would be a good idea to support > > compiling the rust code at a different optimization level than the > > rest of the C code in the kernel? Do we really need that flexibility > > for Rust kernel code, or can we drop this feature? > > I did :P > > The idea is that, since it seemed to work out of the box when I tried, > it could be nice to keep for debugging and for having another degree > of freedom when testing the compiler/nightlies etc. > > Also, it is not intended for users, which is why I put it in the > "hacking" menu -- users should still only modify the usual global > option. > > However, it is indeed strange for the kernel and I don't mind dropping > it if people want to see it out (one could still do it manually if > needed...). > > (Related: from what I have been told, the kernel does not support > lower levels in C just due to old problems with compilers; but those > may be gone now). IIRC the kernel (or at least x86_64 defconfig) cannot be built at -O0, which is too bad if developers were myopically focused on build times. It would have been nice to have something like CONFIG_CC_OPTIMIZE_FOR_COMPILE_TIME to join CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE and CONFIG_CC_OPTIMIZE_FOR_SIZE, but maybe it's still possible to support one day. (¿Por qué no los tres? Perhaps a false-trichotomy? Sorry, but those 3 are somewhat at odds for compilation). Until then, I don't see why we need to permit developers to express such flexibility for just the Rust code, or have it differ from the intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and CC_OPTIMIZE_FOR_SIZE? I doubt it. That doesn't seem like a development feature, but a mistake. YAGNI. Instead developers should clarify what they care about in terms of high level intent; if someone wants to micromanage optimization level flags in their forks they don't need a Kconfig to do it (they're either going to hack KBUILD_CFLAGS, CFLAGS_*.o, or KCFLAGS), and there's probably better mechanisms for fine-tooth precision of optimizing actually hot code or not via PGO and AutoFDO. https://lore.kernel.org/lkml/20210407211704.367039-1-morbo@xxxxxxxxxx/ -- Thanks, ~Nick Desaulniers
