[clang] [llvm] [Clang][BPF] Allow sign extension for call parameters with int types (PR #84874)

pulehui wrote: > The `r1` would be zero extended, while to be ABI conformant it has to be sign > extended, as for RV64 the 31-st bit should be the same as upper 32 bits. The > fact that decision to zero or sign extend the argument depends on the > architecture means that this extension has to

[clang] [llvm] [Clang][BPF] Allow sign extension for call parameters with int types (PR #84874)

pulehui wrote: > @pulehui I will not merge this patch now since it does not really solve the > whole riscv issue. As @4ast commented above, the verifier made btf_func_model > to jit. > [snip] > So you will know whether it is a struct or signed or not. If you feel you > need explicit UNSIGNED f

[clang] [llvm] [Clang][BPF] Allow sign extension for int type call parameters (PR #84874)

pulehui wrote: Thanks Yonghong. It works through the kfunc_call case in no_alu32 mode, as well as other cases in riscv64. Tested-by: Pu Lehui https://github.com/llvm/llvm-project/pull/84874 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http

[clang] [llvm] [Clang][BPF] Allow sign/zero extension for call parameters with int/uint types (PR #84874)

pulehui wrote: > > A kernel function will expect the uint to be sign-extended, not > > zero-extended. > > I suspect riscv bpf jit will do sign-extension. @pulehui can confirm. This > may be true for 32-bit subregisters, but I am not sure whether this is true > for full register or not. Sorry