On Fri, Feb 14, 2025 at 07:04:13PM -0800, Alexei Starovoitov wrote: > > > > How about: > > > > #define BPF_LOAD_ACQ 2 > > > > #define BPF_STORE_REL 3 > > > > > > > > and only use them with BPF_MOV like > > > > > > > > imm = BPF_MOV | BPF_LOAD_ACQ - is actual load acquire > > > > imm = BPF_MOV | BPF_STORE_REL - release > > > > Based on everything discussed, should we proceed with the above > > suggestion? Specifically: > > > > #define BPF_LD_ST BPF_MOV /* 0xb0 */ > > The aliasing still bothers me. > I hated doing it when going from cBPF to eBPF, > but we only had 8-bit to work with. > Here we have 32-bit. > Aliases make disassemblers trickier, since value no longer > translates to string as-is. It depends on the context. > There is probably no use for BPF_MOV operation in atomic > context, but by reusing BPF_ADD, BPF_XOR, etc in atomic > we signed up ourselves for all of alu ops. I see. > That's why BPF_XCHG and BPF_CMPXCHG are outside > of alu op range. > > So my preference is to do: > #define BPF_LOAD_ACQ 0x100 > #define BPF_STORE_REL 0x110 > #define BPF_CMPWAIT_RELAXED 0x120 > > and keep growing it. > We burn the first nibble, but so be it. Got it! In instruction-set.rst I'll make it clear that imm<0-3> must be zero for load_acq/store_rel. Cheers, Peilin Ye
