llvm dev - Jun 2016 - [iovisor-dev] [PATCH, BPF 5/5] BPF: Add 32-bit and pattern

On Thu, Jun 16, 2016 at 10:42 AM, Richard Henderson <rth at twiddle.net>
wrote:
> On 06/15/2016 10:41 PM, Alexei Starovoitov wrote:
>> Do you have further optimizations that take advantage of 32-bit
>> subregisters and zero extension?
>> Should it be added in more generic way instead of pattern match?
>
> This is the last of the operations that can be implemented with just 64-bit
> operands.
>
> A full and proper implementation of 32-bit operations takes quite a bit
more
> effort.  I started on that one evening last week before realizing quite how
> much, and had to put it aside for now.
great. pls share whenever it's ready.
For most cases native 32-bit arithmetic should boost performance.
Currently there are too many <<32 >>32 ops generated.
> More important is probably to get signed division working instead of
emitting
> an error.  I expect it ought to be similar to how Select is expanded, with
> multiple blocks:
interesting idea. we decided not to introduce signed div insn,
since classic bpf doesn't have it and there wasn't a single case
where sdiv couldn't be replaced with udiv in C code,
but such compiler support is certainly nice.
Probably makes sense to add warn_once, so the user
is suggested to tweak the code manually, since these
extra branches not going to help performance.
btw we've been talking about introducing signed/unsigned <, <= ops.
That should clean up llvm side a bit and performance will improve,
but verifier need to work harder, since it pattern matches >
for packet access.
Speaking of verifier... there is a todo item to add register liveness
to improve search pruning.
>
>
>    if (a < 0)
>      a2 = -a
>    a3 = phi(a, a2)
>    if (b < 0)
>      b2 = -b
>    b3 = phi(b, b2)
>    r = a3 / b3
>    if ((a ^ b) < 0)
>      r2 = -r
>    r3 = phi(r, r2)
>
>
> r~