Can we initial Is64Bit to true or false and then we only need to handle 32-bit or 64-bit opcodes in following switch?

Comments need to be updated.

The strange character before "We"

This is redundant or can be changed to an assert?

Any special reason that we don't do the folding after RA when there are multiple uses for SrcMI? Before RA, we do such kind of transformation as it is still benefit. We eliminate the dependancy between SrcMI and MI.

What case will have rlwinm input is rlwinm8 or rlwinm8 input is rlwinm? Just curious.

This is a bit of a bizarre set up that makes it hard to read. How about skipping these switch statements and just doing what you're after:

1. Find the source MI
2. Check if they're both 32-bit or both 64-bit instructions

For 2. you can do something like:

static bool sameWidthRLWINM(MachineInstr *SrcMI, MachineInstr *UseMI,
                            bool &Is64Bit) {
  unsigned SrcOpc = SrcMI->getOpcode();
  unsigned UseOpc = UseMI->getOpcode();
  if ((SrcOpc == PPC::RLWINM8 || SrcOpc == PPC::RLWINM8_rec) &&
      (UseOpc == PPC::RLWINM8 || UseOpc == PPC::RLWINM8_rec)) {
    Is64Bit = true;
    return true;
  }
  if ((SrcOpc == PPC::RLWINM || SrcOpc == PPC::RLWINM_rec) &&
      (UseOpc == PPC::RLWINM || UseOpc == PPC::RLWINM_rec))
    return true;
  Is64Bit = false;
  return false;
}

Can these lines be moved after line 3221? So we will bail out early.

Please describe this "special case" since it appears to be two special cases:
The first part means all bits in a 64-bit register and the second part means the low 32 bits in a 64-bit register.

I am not sure what the intended meaning of lowerest is here, but please use something like least significant bit.

Why can't this whole block be replaced by a call to replaceInstrWithLI()?

I find it unlikely that clang-format produced this formatting.

No need, but is it incorrect to update them? Namely, won't the NewMB/NewME be the same as MBMI/MEMI respectively? If so, I think it is preferable to avoid the condition and leave it to the reader to figure out.

In general, I find that manually messing with kill flags when changing the instructions to be an error-prone thing that should be avoided if possible? Is it possible to re-run the pass that computes kill flags after the peephole?

For example I think that here, if MI.getOperand(1).isKill() before the change, we will not update the kill flag on the previous use of that register so it will be considered live after MI whereas before it wasn't. This is of course not semantically incorrect, but may hinder some optimizations.

Can we set the NoUse for pre-ra also，so that just check the NoUse here？

Same as above, after RA, even SrcMI has multiple uses, we still should do the transform?

Can we move CanErase assignment for SSA to the place where we assign it for post SSA?