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!
