Building the linux kernel with custom CFLAGS

[EliasJonsson]

Dear Gentoo community,
I am building the kernel on a Raspberryu Pi 4. I have tried to add custom cflags to the variable KBUILD_HOSTCFLAGS in the Makefile in the kernel main directory, That did'nt work, none of them show up if I compile with:

[Ionen]

I recall you need to use make KCFLAGS="..." if that still works but don't do it if it can be avoided, things like -ftree-vectorize definitely have no business being there (not familiar with building kernels for the Pi but pretty sure you don't need to set any CFLAGS yourself).

[NeddySeagoon]

EliasJonsson,

Read the Makefile ...

[EliasJonsson]

As NeddySeagoon said, setting the KBUILD_CPPFLAGS and KBUILD_CFLAGS in the main Makefile did the trick.
Omitted a few of the optimization flags as per your recommendations.
Thank you very much for your support!

[Marcih]

I remember there was a patch in the experimental part of genpatches that allowed you to set your -march via the "Processor family" setting in menuconfig that was removed not too long ago. What is now the proper way of compiling with the proper -march for your CPU?
_________________

[EliasJonsson]

I tried building the kernel using a few variations of optimization flags. The one I found working (building successfully and running perfectly) for the Raspberry Pi 4 with the most optimization was:

[Marcih]

[NeddySeagoon]

Marcih,

What -mcpu, -mtune and -march do varies with arch.
If you know what you want for amd64, you need to learn it again for arm64.

We need to know what CPU architecture you have in mind.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Hu]

Yes, -O2 is redundant if already specified and not otherwise changed by any other -O options in the intervening text.

I expect that -mtune=native would do as you intend. However, I think that it is not saying that there are no optimizations. Rather, it is saying that it may skip an optimization that works well for your chosen CPU architecture, if the compiler authors are aware that other allowed CPU architectures perform poorly with that optimization. For example, suppose that in BARv2, there existed an instruction frob that does something useful far more efficiently than open-coding that instruction. In BARv1, the effect must be open-coded because the instruction did not exist. -march=BARv2 would allow use of frob. Suppose further that in BARv3, the chip designers decided that frob took too much silicon, and they removed the instruction, but shipped a kernel hack that knows how to emulate it when the now illegal instruction is it. Code running on BARv3 may wish to avoid frob and open-code the work, since the emulation is slow. Code running on BARv2 should definitely use frob, because it is hardware accelerated. With mtune=generic, the compiler might decide to use the open-coded version because the performance loss on BARv2 is not as bad as the gain on BARv3. It also might decide to use frob anyway, depending on the value judgments made by the compiler authors and what biases they gave the compiler. If you used mtune=barv2, that would hint to the compiler that you care most about performance on BARv2 CPUs and would prefer it make decisions accordingly, even when those decisions produce code that is worse for BARv3. Conversely, you might explicitly set march=barv2 mtune=barv3 to say that the code must run on both v2 and v3 CPUs (so v3-specific instructions are not allowed), but that you expect to run on v3, so bias decisions toward optimal performance on v3, even at the expense of v2.