On Tue, Mar 26, 2019 at 06:05:29PM +0000, Jiong Wang wrote: > After previous patches, verifier has marked those instructions that really > need zero extension on dst_reg. > > It is then for all back-ends to decide how to use such information to > eliminate unnecessary zero extension codegen during JIT compilation. > > One approach is: > 1. Verifier insert explicit zero extension for those instructions that > need zero extension. > 2. All JIT back-ends do NOT generate zero extension for sub-register > write any more. > > The good thing for this approach is no major change on JIT back-end > interface, all back-ends could get this optimization. > > However, only those back-ends that do not have hardware zero extension > want this optimization. For back-ends like x86_64 and AArch64, there is > hardware support, so this optimization should be disabled. > > This patch introduces new sysctl "bpf_jit_32bit_opt" which is the control > variable for whether the optimization should be enabled. > > It is initialized using target hook bpf_jit_hardware_zext which is default > true, meaning the underlying hardware will do zero extension automatically, > therefore the optimization will be disabled. > > Offload targets do not use this native target hook, instead, they could > get the optimization results using bpf_prog_offload_ops.finalize. > > The user could always enable or disable the optimization by using: > > sysctl net/core/bpf_jit_32bit_opt=[0 | 1] I don't think there should be a sysctl for this. 32-bit archs and ppc/sparc should always do it, since there is no downside and for x64/arm64 the verifier won't be inserting shifts because bpf_jit_hardware_zext==true. We probably need a new insn for this. I'm guessing shifts are not always optimal on all archs. There could be arch specific insns that do it. I'd love to hear from arch folks though.
