[PATCH] D72184: [BPF] support atomic instructions
jackmanb added a comment. > I did not see kernel has atomic_store, do you mean atomic_set? Sorry yep I meant `atomic_set` > Do you suggest we also implement atomic_set? There is no need for 64-bit > architecture like x64, right? Yeah actually now I think about it, `atomic_set` is pretty pointless, I think it's only there in the kernel to support strong type-checking of `atomic_t`; It doesn't imply any barriers. I think we can do without it, it makes more sense to implement alongside barrier instructions. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72184/new/ https://reviews.llvm.org/D72184 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added a comment.
BTW to investigate my previous comment I tried compiling this code:
// SPDX-License-Identifier: GPL-2.0
#include
#include
#include
__u64 add64_value = 1;
__u64 add64_result;
__u32 add32_value = 1;
__u32 add32_result;
__u64 add_stack_value_copy;
__u64 add_stack_result;
SEC("fentry/bpf_fentry_test1")
int BPF_PROG(add, int a)
{
__u64 add_stack_value = 1;
add64_result = __sync_fetch_and_add(_value, 2);
add32_result = __sync_fetch_and_add(_value, 2);
add_stack_result = __sync_fetch_and_add(_stack_value, 2);
add_stack_value_copy = add_stack_value;
return 0;
}
__u64 cmpxchg64_value = 1;
__u64 cmpxchg64_result_fail;
__u64 cmpxchg64_result_succeed;
__u32 cmpxchg32_value = 1;
__u32 cmpxchg32_result_fail;
__u32 cmpxchg32_result_succeed;
SEC("fentry/bpf_fentry_test1")
int BPF_PROG(cmpxchg, int a)
{
cmpxchg64_result_fail = __sync_val_compare_and_swap(
_value, 0, 3);
cmpxchg64_result_succeed = __sync_val_compare_and_swap(
_value, 1, 2);
cmpxchg32_result_fail = __sync_val_compare_and_swap(
_value, 0, 3);
cmpxchg32_result_succeed = __sync_val_compare_and_swap(
_value, 1, 2);
return 0;
}
__u64 xchg64_value = 1;
__u64 xchg64_result;
__u32 xchg32_value = 1;
__u32 xchg32_result;
SEC("fentry/bpf_fentry_test1")
int BPF_PROG(xchg, int a)
{
__u64 val64 = 2;
__u32 val32 = 2;
__atomic_exchange(_value, , _result,
__ATOMIC_RELAXED);
__atomic_exchange(_value, , _result,
__ATOMIC_RELAXED);
__atomic_store(_result, , __ATOMIC_SEQ_CST);
return 0;
}
(By modifying this code
to add the `__atomic_store` and then running `make -C
~/src/linux/linux/tools/testing/selftests/bpf -j test_progs` from the base of
the kernel tree)
And got a crash:
$ make -C ~/src/linux/linux/tools/testing/selftests/bpf -j test_progs
make: Entering directory
'/usr/local/google/home/jackmanb/src/linux/linux/tools/testing/selftests/bpf'
CLNG-LLC [test_maps] atomics_test.o
LLVM ERROR: Cannot select: 0x5638e9444528: ch = AtomicStore<(store seq_cst 8
into @xchg64_result)> 0x5638e94445f8, 0x5638e9444660, Constant:i64<2>,
progs/atomics_test.c:59:2 @[ progs/atomics_test.c:52:5 ]
0x5638e9444660: i64 = BPFISD::Wrapper TargetGlobalAddress:i64 0, progs/atomics_test.c:57:2 @[ progs/atomics_test.c:52:5 ]
0x5638e9444b40: i64 = TargetGlobalAddress 0,
progs/atomics_test.c:57:2 @[ progs/atomics_test.c:52:5 ]
0x5638e94628c0: i64 = Constant<2>
In function: xchg
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: llc -mattr=dwarfris -march=bpf -mcpu=v4
-mattr=+alu32 -filetype=obj -o
/usr/local/google/home/jackmanb/src/linux/linux/tools/testing/selftests/bpf/atomics_test.o
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'BPF DAG->DAG Pattern Instruction Selection' on function
'@xchg'
#0 0x5638e543ae1d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/usr/local/bin/llc+0x26f4e1d)
#1 0x5638e5438c14 llvm::sys::RunSignalHandlers()
(/usr/local/bin/llc+0x26f2c14)
#2 0x5638e5438d70 SignalHandler(int) (/usr/local/bin/llc+0x26f2d70)
#3 0x7ff91703b140 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
#4 0x7ff916b1edb1 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7ff916b08537 abort ./stdlib/abort.c:81:7
#6 0x5638e53b393c llvm::report_fatal_error(llvm::Twine const&, bool)
(/usr/local/bin/llc+0x266d93c)
#7 0x5638e53b3a6e (/usr/local/bin/llc+0x266da6e)
#8 0x5638e527bac0 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*)
(/usr/local/bin/llc+0x2535ac0)
#9 0x5638e527c8b1
llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*,
unsigned int) (/usr/local/bin/llc+0x25368b1)
#10 0x5638e527a5d7 llvm::SelectionDAGISel::DoInstructionSelection()
(/usr/local/bin/llc+0x25345d7)
#11 0x5638e52833f5 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/usr/local/bin/llc+0x253d3f5)
#12 0x5638e5287471
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/usr/local/bin/llc+0x2541471)
#13 0x5638e5289dbc
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0)
(/usr/local/bin/llc+0x2543dbc)
#14 0x5638e491a5d4
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/local/bin/llc+0x1bd45d4)
#15 0x5638e4d0a050 llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/local/bin/llc+0x1fc4050)
#16 0x5638e4d0b5dc
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added a comment. I thought a little more about something I was saying in the office hours. I'm pretty sure GCC's `__atomic_store(, , order)` should fail to compile for anything other than `order=__ATOMIC_RELAXED`, since with the current kernel patchset we have `BPF_SET` (which is called `BPF_XCHG` in this LLVM patch) implemented with the kernel's `atomic_store`, which _doesn't imply a barrier_. One alternative solution might be just to scrap `BPF_SET` without `BPF_FETCH` (`BPF_SET | BPF_FETCH` is implemented with `atomic_xchg` which _does_ imply a barrier IIUC). As we discussed in the office hours, `BPF_CMPSET` (called `BPF_CMPXCHG` in this LLVM patch) won't be supported without `BPF_FETCH` Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72184/new/ https://reviews.llvm.org/D72184 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added a comment. Can we please keep barriers out of scope? I think there's a lot of design to be done there and I'd rather just get the core atomics working first. BTW I got [ 31%] Building LanaiGenDAGISel.inc... Included from /usr/local/google/home/jackmanb/src/llvm-project/llvm/lib/Target/BPF/BPF.td:13: /usr/local/google/home/jackmanb/src/llvm-project/llvm/lib/Target/BPF/BPFInstrInfo.td:677:1: error: Pattern doesn't match mayStore = 1 def : Pat<(atomic_fence (timm), (timm)), (SYNC)>; ^ error: pattern conflicts But removing line 677 fixes it. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72184/new/ https://reviews.llvm.org/D72184 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added inline comments.
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:699
+ let Inst{51-48} = addr{19-16}; // base reg
+ let Inst{55-52} = dst;
+ let Inst{47-32} = addr{15-0}; // offset
There is another mismatch between what I implemented in the kernel and what
you've implemented here, which is that I used `dst` as the pointer base and
`src` as the writeback register but you did the opposite.
IIUC what we have here at the moment is `dst = sync_fetch_and_add(*(src + off),
dst);`. The advantage is that `dst` makes more intuitive sense as a writeback
register.
If we instead had `src = sync_fetch_and_add(*(dst + off), src)` we have the
unintuitive writeback to `src`, but now a) the 2nd argument (the addend) makes
more intuitive sense, and b) `dst` being the pointer base is consistent with
the rest of `BPF_STX`.
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:783
+ let Inst{47-32} = addr{15-0}; // offset
+ let Inst{11-8} = new;
+ let Inst{7-4} = BPF_CMPXCHG.Value;
If we go down the route of matching operands with x86 as you have done for
`XFALU64` and `XCHG`, I think we should also do it for cmpxchg.
IIUC this is `dst = atomic_cmpxchg(*(src + off), r0, new);`
But to do it in a single x86 instruction we need to have only 2 operands + the
hard-coded r0. `r0 = atomic_xmpxchg(*(dst + off), r0, src);` would seem most
natural to me.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72184/new/
https://reviews.llvm.org/D72184
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added inline comments.
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:684
+ let Inst{47-32} = addr{15-0}; // offset
+ let Inst{11-8} = val;
+ let Inst{7-4} = Opc.Value;
yonghong-song wrote:
> jackmanb wrote:
> > jackmanb wrote:
> > > jackmanb wrote:
> > > > Sorry I'm a beginner with the LLVM code, could you explain what `val`
> > > > does? I didn't notice this when I looked through here before.
> > > >
> > > > To try and get a clue I tried just removing this line and then
> > > > compiling the following code:
> > > >
> > > > ```C
> > > > // SPDX-License-Identifier: GPL-2.0
> > > > #include
> > > >
> > > > #include
> > > > #include
> > > > #include
> > > >
> > > > __u64 test_data_64 = 0;
> > > > __u64 test1_result = 0;
> > > >
> > > > SEC("fentry/bpf_fentry_test1")
> > > > int BPF_PROG(test1, int a)
> > > > {
> > > > /* atomic_fetch_add(_data_64, 1); */
> > > > test1_result = __sync_fetch_and_add(_data_64, 1);
> > > > return 0;
> > > > }
> > > > ```
> > > >
> > > > And I was able to load and run the program, with the kernel on my WIP
> > > > branch: https://github.com/bjackman/linux-bpf/tree/wips/bpf-atomics-v0
> > > >
> > > > The result looks like this:
> > > >
> > > > ```shell
> > > > $ llvm-objdump -d atomics_test.o
> > > >
> > > > atomics_test.o: file format elf64-bpf
> > > >
> > > >
> > > > Disassembly of section fentry/bpf_fentry_test1:
> > > >
> > > > :
> > > >0: b7 01 00 00 01 00 00 00 r1 = 1
> > > >1: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0
> > > > ll
> > > >3: db 12 00 00 01 00 00 00 r1 = atomic_fetch_add((u64
> > > > *)(r2 + 0), PLEASE submit a bug report to https://bugs.llvm.org/ and
> > > > include the crash backtrace.
> > > > Stack dump:
> > > > 0. Program arguments: llvm-objdump -d atomics_test.o
> > > > Segmentation fault
> > > > ```
> > > >
> > > > Aside from the fact that llvm-objdump crashed, the encoding `db 12 00
> > > > 00 01 00 00 00` seems correct to me. If I add the `let Inst{11-8} =
> > > > val` back in I get `db 12 00 00 01 01 00 00` which I don't understand.
> > > Ah wait, I guess this is adding a 3rd operand register? In my example
> > > it's unclear because it is R1 which is also the dst operand. I was
> > > envisaging we just have semantics like `src = atomic_fetch_add(dst+off,
> > > src)` but you are instead proposing `dst = atomic_fetch_add(dst+off,
> > > val)`?
> > Sorry I mean `dst = atomic_fetch_add(src+off, val)`
> > Sorry I'm a beginner with the LLVM code, could you explain what `val` does?
> > I didn't notice this when I looked through here before.
>
> For the below statement:
> test1_result = __sync_fetch_and_add(_data_64, 1);
>
> 'val' represents the register which holds the value '1'.
>
> bit 4-7 is also used in compare-and-exchange insn as you need a memory
> location, in-register old/new values.
>
> >
> > To try and get a clue I tried just removing this line and then compiling
> > the following code:
> >
> > ```C
> > // SPDX-License-Identifier: GPL-2.0
> > #include
> >
> > #include
> > #include
> > #include
> >
> > __u64 test_data_64 = 0;
> > __u64 test1_result = 0;
> >
> > SEC("fentry/bpf_fentry_test1")
> > int BPF_PROG(test1, int a)
> > {
> > /* atomic_fetch_add(_data_64, 1); */
> > test1_result = __sync_fetch_and_add(_data_64, 1);
> > return 0;
> > }
> > ```
> >
> > And I was able to load and run the program, with the kernel on my WIP
> > branch: https://github.com/bjackman/linux-bpf/tree/wips/bpf-atomics-v0
> >
> > The result looks like this:
> >
> > ```shell
> > $ llvm-objdump -d atomics_test.o
> >
> > atomics_test.o: file format elf64-bpf
> >
> >
> > Disassembly of section fentry/bpf_fentry_test1:
> >
> > :
> >0: b7 01 00 00 01 00 00 00 r1 = 1
> >1: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll
> >3: db 12 00 00 01 00 00 00 r1 = atomic_fetch_add((u64 *)(r2 +
> > 0), PLEASE submit a bug report to https://bugs.llvm.org/ and include the
> > crash backtrace.
> > Stack dump:
> > 0. Program arguments: llvm-objdump -d atomics_test.o
> > Segmentation fault
> > ```
> >
>
> the crash may come from that the 'val' is not encoded properly. I will double
> check.
>
> > Aside from the fact that llvm-objdump crashed, the encoding `db 12 00 00 01
> > 00 00 00` seems correct to me. If I add the `let Inst{11-8} = val` back in
> > I get `db 12 00 00 01 01 00 00` which I don't understand.
>
> in this particular case, yes, as final asm code looks like
>r1 = atomic_fetch_add((u64 *)(r2 + 0), r1)
> where the value "r1" and the result "r1" shared the same register. A little
> bit compiler work is need to enforce "val" register and result register
> always the same.
>
> My current design allows:
> r3 = atomic_fetch_add((u64 *)(r2 + 0), r1)
> and I think this is
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added inline comments.
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:684
+ let Inst{47-32} = addr{15-0}; // offset
+ let Inst{11-8} = val;
+ let Inst{7-4} = Opc.Value;
jackmanb wrote:
> jackmanb wrote:
> > Sorry I'm a beginner with the LLVM code, could you explain what `val` does?
> > I didn't notice this when I looked through here before.
> >
> > To try and get a clue I tried just removing this line and then compiling
> > the following code:
> >
> > ```C
> > // SPDX-License-Identifier: GPL-2.0
> > #include
> >
> > #include
> > #include
> > #include
> >
> > __u64 test_data_64 = 0;
> > __u64 test1_result = 0;
> >
> > SEC("fentry/bpf_fentry_test1")
> > int BPF_PROG(test1, int a)
> > {
> > /* atomic_fetch_add(_data_64, 1); */
> > test1_result = __sync_fetch_and_add(_data_64, 1);
> > return 0;
> > }
> > ```
> >
> > And I was able to load and run the program, with the kernel on my WIP
> > branch: https://github.com/bjackman/linux-bpf/tree/wips/bpf-atomics-v0
> >
> > The result looks like this:
> >
> > ```shell
> > $ llvm-objdump -d atomics_test.o
> >
> > atomics_test.o: file format elf64-bpf
> >
> >
> > Disassembly of section fentry/bpf_fentry_test1:
> >
> > :
> >0: b7 01 00 00 01 00 00 00 r1 = 1
> >1: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll
> >3: db 12 00 00 01 00 00 00 r1 = atomic_fetch_add((u64 *)(r2 +
> > 0), PLEASE submit a bug report to https://bugs.llvm.org/ and include the
> > crash backtrace.
> > Stack dump:
> > 0. Program arguments: llvm-objdump -d atomics_test.o
> > Segmentation fault
> > ```
> >
> > Aside from the fact that llvm-objdump crashed, the encoding `db 12 00 00 01
> > 00 00 00` seems correct to me. If I add the `let Inst{11-8} = val` back in
> > I get `db 12 00 00 01 01 00 00` which I don't understand.
> Ah wait, I guess this is adding a 3rd operand register? In my example it's
> unclear because it is R1 which is also the dst operand. I was envisaging we
> just have semantics like `src = atomic_fetch_add(dst+off, src)` but you are
> instead proposing `dst = atomic_fetch_add(dst+off, val)`?
Sorry I mean `dst = atomic_fetch_add(src+off, val)`
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72184/new/
https://reviews.llvm.org/D72184
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added inline comments.
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:684
+ let Inst{47-32} = addr{15-0}; // offset
+ let Inst{11-8} = val;
+ let Inst{7-4} = Opc.Value;
jackmanb wrote:
> Sorry I'm a beginner with the LLVM code, could you explain what `val` does? I
> didn't notice this when I looked through here before.
>
> To try and get a clue I tried just removing this line and then compiling the
> following code:
>
> ```C
> // SPDX-License-Identifier: GPL-2.0
> #include
>
> #include
> #include
> #include
>
> __u64 test_data_64 = 0;
> __u64 test1_result = 0;
>
> SEC("fentry/bpf_fentry_test1")
> int BPF_PROG(test1, int a)
> {
> /* atomic_fetch_add(_data_64, 1); */
> test1_result = __sync_fetch_and_add(_data_64, 1);
> return 0;
> }
> ```
>
> And I was able to load and run the program, with the kernel on my WIP branch:
> https://github.com/bjackman/linux-bpf/tree/wips/bpf-atomics-v0
>
> The result looks like this:
>
> ```shell
> $ llvm-objdump -d atomics_test.o
>
> atomics_test.o: file format elf64-bpf
>
>
> Disassembly of section fentry/bpf_fentry_test1:
>
> :
>0: b7 01 00 00 01 00 00 00 r1 = 1
>1: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll
>3: db 12 00 00 01 00 00 00 r1 = atomic_fetch_add((u64 *)(r2 +
> 0), PLEASE submit a bug report to https://bugs.llvm.org/ and include the
> crash backtrace.
> Stack dump:
> 0. Program arguments: llvm-objdump -d atomics_test.o
> Segmentation fault
> ```
>
> Aside from the fact that llvm-objdump crashed, the encoding `db 12 00 00 01
> 00 00 00` seems correct to me. If I add the `let Inst{11-8} = val` back in I
> get `db 12 00 00 01 01 00 00` which I don't understand.
Ah wait, I guess this is adding a 3rd operand register? In my example it's
unclear because it is R1 which is also the dst operand. I was envisaging we
just have semantics like `src = atomic_fetch_add(dst+off, src)` but you are
instead proposing `dst = atomic_fetch_add(dst+off, val)`?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72184/new/
https://reviews.llvm.org/D72184
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [BPF] support atomic instructions
jackmanb added a comment.
Sorry I was disrupted and not able to work on this last week! I've just got
started trying to integrate this with my kernel patches.
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:666
+def XADDD : XADD;
+ }
+}
FYI - I just spotted some stray `\t` in here (is it helpful to point this out?
If not let me know, I will ignore in future)
Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:684
+ let Inst{47-32} = addr{15-0}; // offset
+ let Inst{11-8} = val;
+ let Inst{7-4} = Opc.Value;
Sorry I'm a beginner with the LLVM code, could you explain what `val` does? I
didn't notice this when I looked through here before.
To try and get a clue I tried just removing this line and then compiling the
following code:
```C
// SPDX-License-Identifier: GPL-2.0
#include
#include
#include
#include
__u64 test_data_64 = 0;
__u64 test1_result = 0;
SEC("fentry/bpf_fentry_test1")
int BPF_PROG(test1, int a)
{
/* atomic_fetch_add(_data_64, 1); */
test1_result = __sync_fetch_and_add(_data_64, 1);
return 0;
}
```
And I was able to load and run the program, with the kernel on my WIP branch:
https://github.com/bjackman/linux-bpf/tree/wips/bpf-atomics-v0
The result looks like this:
```shell
$ llvm-objdump -d atomics_test.o
atomics_test.o: file format elf64-bpf
Disassembly of section fentry/bpf_fentry_test1:
:
0: b7 01 00 00 01 00 00 00 r1 = 1
1: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll
3: db 12 00 00 01 00 00 00 r1 = atomic_fetch_add((u64 *)(r2 + 0),
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: llvm-objdump -d atomics_test.o
Segmentation fault
```
Aside from the fact that llvm-objdump crashed, the encoding `db 12 00 00 01 00
00 00` seems correct to me. If I add the `let Inst{11-8} = val` back in I get
`db 12 00 00 01 01 00 00` which I don't understand.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72184/new/
https://reviews.llvm.org/D72184
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D72184: [WIP][BPF] support exchange/compare-and-exchange instruction
jackmanb added inline comments. Comment at: llvm/lib/Target/BPF/BPFInstrFormats.td:98 + +def BPF_ATOMIC_FETCH : BPFAtomicFlag<0x1>; Per Alexei's email comments let's call this BPF_FETCH? Comment at: llvm/lib/Target/BPF/BPFInstrInfo.td:765 + def XCHGB : XCHG; + def XCHGH : XCHG; + def XCHGW : XCHG; I don't know if we want to define these for 16 and 8bit operands - XADD isn't defined for those. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72184/new/ https://reviews.llvm.org/D72184 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
