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

[Pu Lehui via llvm-commits]

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(0x7FFFFFFFU, 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 = 0x7fffffff
1:       85 10 00 00 ff ff ff ff call -0x1
```
but if a = 4294967294(0xFFFFFFFEU, 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 = 0xfffffffe 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