peilin-ye wrote:
> In the above, you will do unsigned load extension. But what about signed
extension load variant?
@yonghong-song, if we ever need that, we can add a new flag to bit `0-3` of
`imm` to indicate "this 8- or 16-bit load-acquire is sign-extending", just like
`BPF_FETCH` for `BPF_XCHG` and `BPF_CMPXCHG`.
However, I wonder how do I generate a sign-extending (`sext`), acquiring
`ATOMIC_LOAD` in SelectionDAG? If I compile the following program:
```c
// clang --target=bpf -mcpu=v4 -mllvm -debug-only=isel-dump -O2 -g -c -o
demo.bpf.o demo.bpf.c
long bar(char *ptr) {
return __atomic_load_n(ptr, __ATOMIC_ACQUIRE);
}
```
I get this:
```
Optimized legalized selection DAG: %bb.0 'bar:entry'
SelectionDAG has 10 nodes:
t0: ch,glue = EntryToken
t2: i64,ch = CopyFromReg t0, Register:i64 %0
t8: i32,ch = AtomicLoad<(load acquire (s8) from %ir.ptr), zext from i8> t0,
t2, demo.bpf.c:3:12
t9: i64 = any_extend t8, demo.bpf.c:3:12
t11: i64 = sign_extend_inreg t9, ValueType:ch:i8, demo.bpf.c:3:12
t6: ch,glue = CopyToReg t8:1, Register:i64 $r0, t11, demo.bpf.c:3:5
t7: ch = BPFISD::RET_GLUE t6, Register:i64 $r0, t6:1, demo.bpf.c:3:5
```
The `AtomicLoad` node (`t8`) still says `zext` (zero-extending). The program
would still work because it does an 8-to-64-bit `MOVSX` after the load-acquire:
```
; return __atomic_load_n(ptr, __ATOMIC_ACQUIRE);
0: d3 11 00 00 10 00 00 00 w1 = load_acquire((u8 *)(r1 + 0x0))
1: bf 10 08 00 00 00 00 00 r0 = (s8)r1
2: 95 00 00 00 00 00 00 00 exit
```
`r0 = (s8)r1` takes the lowest byte of `r1` and sign-extends it into 64-bit, so
it doesn't matter if the load-acquire zero- or sign-extended the char into
32-bit.
I still wonder if there's a way to change that `AtomicLoad` node (`t8`) from
`zext` to `sext` though.
https://github.com/llvm/llvm-project/pull/108636
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
