[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 be done at JIT time (meaning > that BTF is mandatory) or be a part of kfunc. Thanks for the clarification. riscv64 will do sign-extension both for int and uint. For uint, zero-extension is required, but after my investigation, it will be handled in the callee. https://github.com/llvm/llvm-project/pull/84874 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 flag, you can add it in btf as well. > > Let us try to resolve the issue in riscv backend. Thanks! Thanks Yonghong and Alexei, will try to resolve this incompatibility between bpf abi and riscv abi. https://github.com/llvm/llvm-project/pull/84874 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[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 for late.
riscv64 will do sign-extension for 'unsigned int' and riscv64 bpf JIT will do
the same. We need to explicitly zero-extend it. But I don't have problems with
‘unsigned int‘ **before this patch**.
```
void bpf_kfunc_call_test4(unsigned int a) __ksym;
int kfunc_call_test4(struct __sk_buff *skb) {
unsigned int a = xxx;
bpf_kfunc_call_test4(a);
}
```
if a = 2147483647(0x7FFFU, bit 31 is 0), it will be a mov insn. It will be
valid 'unsigned int' in kfunc after sign-extension.
```
0: b7 01 00 00 ff ff ff 7f r1 = 0x7fff
1: 85 10 00 00 ff ff ff ff call -0x1
```
but if a = 4294967294(0xFFFEU, bit 31 is 1), it will be a ld_imm64 insn.
And it also be valid 'unsigned int' in kfunc.
```
0: 18 01 00 00 fe ff ff ff 00 00 00 00 00 00 00 00 r1 = 0xfffe ll
2: 85 10 00 00 ff ff ff ff call -0x1
```
But **after this patch**, the two numbers get the same result as before this
patch. I don't see ld_imm64 becoming a mov instruction, as well as explicit
zero extension for 'unsigned int'. Is that expected?
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
