Jiong Wang writes:
<snip> > At the moment we have single backend hook "bpf_jit_hardware_zext", once a > backend enable it, verifier just insert zero extension for all identified > alu32 and narrow loads. > > Given verifier analysis info is not pushed down to JIT back-ends, verifier > needs more back-end info pushed up from back-ends. Do you think make sense > to introduce another hook "bpf_jit_hardware_zext_narrow_load" Maybe just keep the current "bpf_jit_hardware_zext", but let it return int/enum instead of bool. Then verifier could know hardware ability through the enum value? > to at least > prevent unnecessary zext inserted for narrowed loads for arches like > PowerPC, SPARC? > > The hooks to control verifier zext insertion then becomes two: > > bpf_jit_hardware_zext_alu32 > bpf_jit_hardware_zext_narrow_load > >>> And that why I introduce these new argument types, without them, there >>> could be more than 10% extra zext inserted on benchmarks like bpf_lxc. >> >> 10% extra ? so be it. >> We're talking past each other here. >> I agree with your optimization goal, but I think you're missing >> the safety concerns I'm trying to explain. >>> But for helper functions, they are done by native code which may not follow >>> this convention. For example, on arm32, calling helper functions are just >>> jump to and execute native code. And if the helper returns u32, it just set >>> r0, no clearing of r1 which is the high 32-bit in the register pair >>> modeling eBPF R0. >> >> it's arm32 bug then. All helpers _must_ return 64-bit back to bpf prog >> and _must_ accept 64-bit from bpf prog.
