Andrii Nakryiko wrote: > Switch most of BPF helper definitions from returning int to long. These > definitions are coming from comments in BPF UAPI header and are used to > generate bpf_helper_defs.h (under libbpf) to be later included and used from > BPF programs. [...] > There could be two variations with slightly different code generated: when len > is 64-bit integer and when it is 32-bit integer. Both variations were analysed. > BPF assembly instructions between two successive invocations of > bpf_probe_read_kernel_str() were used to check code regressions. Results are > below, followed by short analysis. Left side is using helpers with int return > type, the right one is after the switch to long. > > ALU32 + INT ALU32 + LONG > =========== ============ > > 64-BIT (13 insns): 64-BIT (10 insns): > ------------------------------------ ------------------------------------ > 17: call 115 17: call 115 > 18: if w0 > 256 goto +9 <LBB0_4> 18: if r0 > 256 goto +6 <LBB0_4> > 19: w1 = w0 19: r1 = 0 ll > 20: r1 <<= 32 21: *(u64 *)(r1 + 0) = r0 > 21: r1 s>>= 32 22: r6 = 0 ll If you roll a v3 for Alexei's comment might be worth mentioning that above <<=,s>> is a result of the >256 test if you do this as a more standard <0 test the 'w1 = w0' assignment should be enough. > 22: r2 = 0 ll 24: r6 += r0 > 24: *(u64 *)(r2 + 0) = r1 00000000000000c8 <LBB0_4>: > 25: r6 = 0 ll 25: r1 = r6 > 27: r6 += r1 26: w2 = 256 > 00000000000000e0 <LBB0_4>: 27: r3 = 0 ll > 28: r1 = r6 29: call 115 > 29: w2 = 256 > 30: r3 = 0 ll > 32: call 115 > Thanks, John
