[all-commits] [llvm/llvm-project] 13f6c8: [BPF] simplify zero extension with MOV_32_64

[John Fastabend via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 13f6c81c5d9a7a34a684363bcaad8eb7c65356fd
      https://github.com/llvm/llvm-project/commit/13f6c81c5d9a7a34a684363bcaad8eb7c65356fd
  Author: John Fastabend <john.fastabend at gmail.com>
  Date:   2020-05-27 (Wed, 27 May 2020)

  Changed paths:
    M llvm/lib/Target/BPF/BPFISelLowering.cpp
    M llvm/lib/Target/BPF/BPFInstrInfo.td
    M llvm/lib/Target/BPF/BPFMIPeephole.cpp
    M llvm/test/CodeGen/BPF/32-bit-subreg-cond-select.ll
    M llvm/test/CodeGen/BPF/32-bit-subreg-peephole-phi-1.ll
    M llvm/test/CodeGen/BPF/32-bit-subreg-peephole-phi-2.ll
    M llvm/test/CodeGen/BPF/32-bit-subreg-peephole-phi-3.ll
    M llvm/test/CodeGen/BPF/32-bit-subreg-peephole.ll
    A llvm/test/CodeGen/BPF/32-bit-subreg-zext.ll

  Log Message:
  -----------
  [BPF] simplify zero extension with MOV_32_64

The current pattern matching for zext results in the following code snippet
being produced,

  w1 = w0
  r1 <<= 32
  r1 >>= 32

Because BPF implementations require zero extension on 32bit loads this
both adds a few extra unneeded instructions but also makes it a bit
harder for the verifier to track the r1 register bounds. For example in
this verifier trace we see at the end of the snippet R2 offset is unknown.
However, if we track this correctly we see w1 should have the same bounds
as r8. R8 smax is less than U32 max value so a zero extend load should keep
the same value. Adding a max value of 800 (R8=inv(id=0,smax_value=800)) to
an off=0, as seen in R7 should create a max offset of 800. However at the
end of the snippet we note the R2 max offset is 0xffffFFFF.

  R0=inv(id=0,smax_value=800)
  R1_w=inv(id=0,umax_value=2147483647,var_off=(0x0; 0x7fffffff))
  R6=ctx(id=0,off=0,imm=0) R7=map_value(id=0,off=0,ks=4,vs=1600,imm=0)
  R8_w=inv(id=0,smax_value=800,umax_value=4294967295,var_off=(0x0; 0xffffffff))
  R9=inv800 R10=fp0 fp-8=mmmm????
 58: (1c) w9 -= w8
 59: (bc) w1 = w8
 60: (67) r1 <<= 32
 61: (77) r1 >>= 32
 62: (bf) r2 = r7
 63: (0f) r2 += r1
 64: (bf) r1 = r6
 65: (bc) w3 = w9
 66: (b7) r4 = 0
 67: (85) call bpf_get_stack#67
  R0=inv(id=0,smax_value=800)
  R1_w=ctx(id=0,off=0,imm=0)
  R2_w=map_value(id=0,off=0,ks=4,vs=1600,umax_value=4294967295,var_off=(0x0; 0xffffffff))
  R3_w=inv(id=0,umax_value=800,var_off=(0x0; 0x3ff))
  R4_w=inv0 R6=ctx(id=0,off=0,imm=0)
  R7=map_value(id=0,off=0,ks=4,vs=1600,imm=0)
  R8_w=inv(id=0,smax_value=800,umax_value=4294967295,var_off=(0x0; 0xffffffff))
  R9_w=inv(id=0,umax_value=800,var_off=(0x0; 0x3ff))
  R10=fp0 fp-8=mmmm????

After this patch R1 bounds are not smashed by the <<=32 >>=32 shift and we
get correct bounds on R2 umax_value=800.

Further it reduces 3 insns to 1.

Signed-off-by: John Fastabend <john.fastabend at gmail.com>

Differential Revision: https://reviews.llvm.org/D73985