yonghong-song wrote:
Just uploaded a new revision which targets 'Int' type only, i.e, v1.
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/yonghong-song edited
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
https://github.com/yonghong-song updated
https://github.com/llvm/llvm-project/pull/84874
>From 3c3ce0ddef2cc9955b00317aaec69406f38b86f6 Mon Sep 17 00:00:00 2001
From: Yonghong Song
Date: Mon, 11 Mar 2024 22:27:37 -0700
Subject: [PATCH] [Clang][BPF] Allow sign extension for int type call
yonghong-song wrote:
> @yonghong-song , if I understand @efriedma-quic correctly (thank you for
> explanations), the following fragment is not RISC-V ABI conformant:
>
> ```
> $ cat u.c
> void foo(unsigned);
> void bar(unsigned a, unsigned b) {
> foo(a + b);
> }
>
>1: 67 02 00
yonghong-song wrote:
> 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?
IIUC, we have the same result before and after this patch.
eddyz87 wrote:
@yonghong-song , if I understand @efriedma-quic correctly (thank you for
explanations), the following fragment is not RISC-V ABI conformant:
```
$ cat u.c
void foo(unsigned);
void bar(unsigned a, unsigned b) {
foo(a + b);
}
1: 67 02 00 00 20 00 00 00 r2 <<= 0x20
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.
https://github.com/inclyc approved this pull request.
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
yonghong-song wrote:
For this one:
> 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.
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits
efriedma-quic wrote:
> My understanding is that you refer to the following part of the
> [specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf):
Yes. For example, on RISC-V, the function `long f(unsigned g) { return (int)g;
}` compiles to just a "ret".
> clang would
yonghong-song wrote:
@pulehui Could you check whether with -mcpu=v2 (no-alu32 mode) we have
'unsigned int' related issue or not? Specifically, given a 'unsigned int' does
riscv use subregister to access 32-bit value, or use 64-bit register to access
the value without zero-extension of 32-bit
yonghong-song wrote:
The following is an example to show 'unsigned int' case. The current behavior
(i.e., without this patch):
```
$ cat u.c
void foo(unsigned);
void bar(unsigned a, unsigned b) {
foo(a + b);
}
$ clang --target=bpf -O2 -c u.c && llvm-objdump -d u.o
u.o:file format
eddyz87 wrote:
Hi @efriedma-quic,
> That said, this isn't handling "unsigned int" correctly. "unsigned int" is
> supposed to be sign-extended on RISC-V targets. (How you resolve the conflict
> with PowerPC, where "unsigned int" is supposed to be zero-extended, I'm not
> sure.)
Could you
https://github.com/eddyz87 approved this pull request.
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
https://github.com/efriedma-quic edited
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
https://github.com/efriedma-quic commented:
Oh, this is making a bit more sense now... I didn't realize this was overriding
method that handles char/short already. And I guess for BPF targets, you can
assume "long" is 64 bits.
That said, this isn't handling "unsigned int" correctly.
yonghong-song wrote:
@efriedma-quic Thanks for your comments. BPF llvm backend and kernel BPF jit
try to make BPF<->other_architecture compatible. riscv started to support BPF
starting in 2020 and probably BPF has limited usage so the bug is exposed until
now.
Yes,
https://github.com/yonghong-song updated
https://github.com/llvm/llvm-project/pull/84874
>From 2f0bb4f039d9b0ceb8e014b85c68050b65726d3d Mon Sep 17 00:00:00 2001
From: Yonghong Song
Date: Mon, 11 Mar 2024 22:27:37 -0700
Subject: [PATCH] [Clang][BPF] Allow sign/zero extension for call parameters
https://github.com/yonghong-song edited
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
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff c4e517f59c086eafe2eb61d23197820f05be799c
e2a62512b1693d06dc3421d93de17fc248a6a496 --
https://github.com/yonghong-song edited
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
21 matches
Mail list logo
