[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.

> Seems something went wrong here? I'll look into it tomorrow but its not what I expected on two cases. First I expected a jmp32 op and second that last optimization seems wrong?

I checked the code. I agree with you that optimization seems not right.
In `BPFMIPeephole.cpp`,  we have

  // Eliminate identical move:
  //
  //   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.
  unsigned Opcode = MI.getOpcode();
  if (Opcode == BPF::MOV_32_64 ||
      Opcode == BPF::MOV_rr || Opcode == BPF::MOV_rr_32) {
    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;
  
    ToErase = &MI;
    RedundantMovElemNum++;
    Eliminated = true;
  }

`MOV_32_64` actually problematic here as it is not a simple register copy, it has side effect.
The same as `MOV_rr_32`. it also has a side effect to zero out the top bits. We cannot simply remove
them.

What we need to do is to further trace def/use chain, unless the 32bit reg already has upper bits
zeroed, we should not do the optimization.

Will work on a fix ASAP. Thanks for spotting the problem!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73985