[llvm-dev] [iovisor-dev] [PATCH, BPF 4/5] BPF: Add 32-bit move patterns

[Alexei Starovoitov via llvm-dev]

On Thu, Jun 16, 2016 at 10:28 AM, Richard Henderson <rth at twiddle.net> wrote:
> On 06/15/2016 10:38 PM, Alexei Starovoitov wrote:
>> but before we go too far with new asm syntax like 'movw',
>> Do you want to revamp the whole thing?
>> imo the kernel verifier asm output is easier to read
>> due to being C-like and now more people understand it
>> vs what llvm bpf backend produces.
>
> While the kernel verifier format is ok for the 64-bit opcodes, I personally
> can't stand what it does for the 32-bit opcodes, e.g.
>
>         (u32) r0 += (u32) r1
>
> That's not only unnecessarily verbose, it's bad C.

sure. we didn't have llvm producing 32-bit opcodes,
so that part was a quick hack.
Looking at your elfutils patch that does:
r%1$d = (u32)r%1$d + (u32)r%2$d
that totally makes sense to me.
I can change kernel to do that as well.
What I'm suggesting is to teach llvm backend to output that
elfutils style as well.

>> Right now we have two asms: what kernel verifier prints
>> and llvm bpf asm output. Kernel side we cannot drastically
>> change anymore, but minor changes should be ok if it
>> helps to converge to one common bpf asm syntax.
>
> Why, is the kernel verifier output considered part of the abi now?  That seems
> like an odd position to take.
>
> I also have a disassembler written for elfutils, so that it ties in nicely with
> objdump.  I started with tweaks to the kernel output (which can be seen in the
> post I quoted earlier), but have since changed to use the llvm disassembly (and
> have not yet re-posted).

what was posted in elfutils is preferred to me.
We can cleanup kernel output for 32-bit like you did,
but we cannot change it drastically, since plenty of users already
learned to understand the verifier output which especially important
in case of program rejects.