On Mon, Jul 29, 2024 at 8:49 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
> > > instruction with 'asm volatile ("" ::: "memory");' semantics might be tricky.
> >
> > It can be a standalone insn that is a compiler barrier only but that feels like
> > a waste of an instruction. So depending how we end up encoding various
> > real barriers
> > there may be a bit to spend in such a barrier insn that is only a
> > compiler barrier.
> > In this case optimizing JIT barrier.
>
> When reading BPF instructions back into a compiler backend, would
> it make sense to convert an acquire-load instruction back to
> __atomic_load_n(... memorder=__ATOMIC_ACQUIRE)? Or the internal
> representation thereof?
Internal representation?
We need to pick asm mnemonics for ld_acq insn, but pushing
C-like asm to emit __atomic_load_n() in disasm is imo too much.
Currently LDX insn will be disasm-ed to r1 = *(u32 *)r2;
For load acquire insn we can emit r1 = smp_load_acquire_u32(r2);
or r1 = load_acquire((u32 *)r2);
