[PATCH] D81048: [BPF] Remove unnecessary MOV_32_64 instructions

[Yonghong Song via Phabricator via llvm-commits]

yonghong-song created this revision.
yonghong-song added reviewers: ast, anakryiko.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a project: LLVM.

Commit 13f6c81c5d9a <https://reviews.llvm.org/rG13f6c81c5d9a7a34a684363bcaad8eb7c65356fd> ("[BPF] simplify zero extension
with MOV_32_64") tried to use MOV_32_64 instructions
instead of lshift/rshift instructions for zero extension.
This has the benefit to remove the number of instructions
and may help verifier too.

But the same commit also removed the old MOV_32_64
pruning as it deems unsafe as MOV_32_64 does have the 
side effect, zeroing out the top 32bit in the register.
This caused the following failure in kernel selftest
test_cls_redirect.o. In linux kernel, we have

  struct __sk_buff {
     __u32 data;
     __u32 data_end;
  }; 

The compiler will generate 32bit load for __sk_buff->data
and __sk_buff->data_end. But kernel verifier will actually
loads an address (64bit address on 64bit kernel) to the 
result register. In this particular example, the explicit zext
was not optimized away and destroyed top 32bit
address and the verifier rejected the program :

  w2 = *(u32 *)(r1 + 76) 
  ... 
  r2 = w2  /* MOV_32_64: this will clear top 32bit */

Currently, if the load and the zext are next to each other, the 
instruction pattern match can actually capture this to
avoid MOV_32_64, e.g., in BPFInstrInfo.td, we have

  def : Pat<(i64 (zextloadi32 ADDRri:$src)),
            (SUBREG_TO_REG (i64 0), (LDW32 ADDRri:$src), sub_32)>;

However, if they are not next to each other, LDW32 and 
MOV_32_64 are generated, which may cause the above mentioned
problem.

BPF Backend already tried to optimize away pattern

  mov_32_64 + lshift + rshift

Commit 13f6c81c5d9a <https://reviews.llvm.org/rG13f6c81c5d9a7a34a684363bcaad8eb7c65356fd> may generate mov_32_64 not followed by shifts.
This patch added optimization for mov_32_64 too.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D81048

Files:
  llvm/lib/Target/BPF/BPFMIPeephole.cpp
  llvm/test/CodeGen/BPF/remove_truncate_7.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D81048.268033.patch
Type: text/x-patch
Size: 3961 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200603/c2490f7e/attachment.bin>