[PATCH] D73985: [bpf] zero extension is required in BPF implementaiton so remove <<=32 >>=32

[Yonghong Song via Phabricator via llvm-commits]

yonghong-song added a comment.

I think the following are the steps we should take:

1. We need to fold the following change to this commit:

  diff --git a/llvm/lib/Target/BPF/BPFMIPeephole.cpp b/llvm/lib/Target/BPF/BPFMIPeephole.cpp 
  index a2ceade6680..fe955fad042 100644 
  --- a/llvm/lib/Target/BPF/BPFMIPeephole.cpp 
  +++ b/llvm/lib/Target/BPF/BPFMIPeephole.cpp 
  @@ -301,19 +301,16 @@ bool BPFMIPreEmitPeephole::eliminateRedundantMov(void) { 
         // 
         //   MOV rA, rA 
         // 
  -      // This is particularly possible to happen when sub-register support 
  -      // enabled. The special type cast insn MOV_32_64 involves different 
  -      // register class on src (i32) and dst (i64), RA could generate useless 
  -      // instruction due to this. 
  +      // Note that we cannot remove 
  +      //   MOV_32_64  rA, wA 
  +      //   MOV_rr_32  wA, wA 
  +      // as these two instructions having side effects, zeroing out 
  +      // top 32 bits of rA. 
         unsigned Opcode = MI.getOpcode(); 
  -      if (Opcode == BPF::MOV_32_64 || 
  -          Opcode == BPF::MOV_rr || Opcode == BPF::MOV_rr_32) { 
  +      if (Opcode == BPF::MOV_rr) { 
           Register dst = MI.getOperand(0).getReg(); 
           Register src = MI.getOperand(1).getReg(); 
    
  -        if (Opcode == BPF::MOV_32_64) 
  -          dst = TRI->getSubReg(dst, BPF::sub_32); 
  - 
           if (dst != src) 
             continue;

We do not this problem before since MOV_32_64 is always generated together with shifts and that is taken care of by SSA peephole optimization.

But since this patch may generate MOV_32_64 without shifts, we need to make this change.

@jrfastab could you take care of this?

2. optionally, we need to enhance SSA peephole optimization for MOV_32_64 without shift case. This is only one inst since there are no shifts. We can do it later if we do not want to do it in this patch.

@jrfastab  you can take a look at BPFMIPeephole.cpp to see whether you want to do the optimization now or delay to later.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73985/new/

https://reviews.llvm.org/D73985