HomePhabricator

[BPF] Remove unnecessary MOV_32_64 instructions

Authored by yonghong-song on Jun 2 2020, 12:47 AM.

Description

[BPF] Remove unnecessary MOV_32_64 instructions

Commit 13f6c81c5d9a ("[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 may generate mov_32_64 not followed by shifts.
This patch added optimization for only mov_32_64 too.

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

Details

Committed
yonghong-songJun 3 2020, 8:14 AM
Differential Revision
D81048: [BPF] Remove unnecessary MOV_32_64 instructions
Parents
rG3653c1bbed01: Fix gcc -Wdocumentation warning. NFC.
Branches
Unknown
Tags
Unknown