CO-RE builtins purity and other compiler optimizations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello BPF people!

We are still working in supporting the pending CO-RE built-ins in GCC.
The trick of hooking in the parser to avoid constant folding, as
discussed during LSFMMBPF, seems to work well.  Almost there!

So, most of the CO-RE associated C built-ins have the side effect of
emiting a CO-RE relocation in the .BTF.ext section.  This is for example
the case of __builtin_preserve_enum_value.

Like calls to regular functions, calls to C built-ins are also
candidates to certain optimizations.  For example, given this code:

: int a = __builtin_preserve_enum_value(*(typeof(enum E) *)eB, BPF_ENUMVAL_VALUE);
: int b = __builtin_preserve_enum_value(*(typeof(enum E) *)eB, BPF_ENUMVAL_VALUE);

The compiler may very well decide to optimize out the second call to the
built-in if it is to be considered "pure", i.e. given exactly the same
arguments it produces the same results.

We observed that clang indeed seems to optimize that way.  See
https://godbolt.org/z/zqe9Kfrrj.

That kind of optimizations have an impact on the number of CO-RE
relocations emitted.

Question:

Is the BPF loader, the BPF verifier or any other core component sensible
in any way to the number (and ordering) of CO-RE relocations for some
given BPF C program?  i.e. compiling the same BPF C program above with
and without that optimization, will it work in both cases?

If no, then perfect!  Different compilers can optimize slightly
differently (or not optimize at all) and we can mark these built-ins as
pure in GCC as well, benefiting from optimizations without worrying to
have to emit exactly what clang emits.

If yes, wouldn't it be better to disable that kind of optimization in
all C BPF compilers, i.e. to make the compilers aware of the side-effect
so they will not optimize built-in calls out (or replicate them.) and to
make this mandatory in the CO-RE spec?  Making a compiler to optimize
exactly like another compiler is difficult and sometimes even not
feasible.

Thanks in advance for the clarification/info!




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux