Where does the function visitORR check the upper bits are zero?

When I take a look at the function AArch64MIPeepholeOpt::visitORR,it has some comment that the function will check the upper bits of the destination registers are zero.

But I doesn’t see the matched logic, does any guy known where is check of the upper bits?

The check is SrcMI->getOpcode() <= TargetOpcode::GENERIC_OP_END. We assume any target-specific instruction zeros the high bits of the destination. See ⚙ D110841 [AArch64] Remove redundant ORRWrs which is generated by zero-extend for more.

Thanks @efriedma-quic very much.
BTW, does the check SrcMI->getOpcode() <= TargetOpcode::GENERIC_OP_END depend on the following pattern defined in the backend ? or it is absolutely true for target-specific instruction?

//In the case of a 32-bit def that is known to implicitly zero-extend,
//we can use a SUBREG_TO_REG.
def : Pat<(i64 (zext def32:$src)),
          (SUBREG_TO_REG (i64 0), GPR32:$src, sub_32)>;

What version of LLVM are you looking at? We killed off def32 because it was impossible to define correctly. See ⚙ D127154 [AArch64] Remove isDef32 .

1 Like

Oh, sorry. I just copy the context from the link :gear: D110841 [AArch64] Remove redundant ORRWrs which is generated by zero-extend above.

Yes, it now was killed off.

My understanding is that it’s from Documentation – Arm Developer (the link in the comment)

When you use the 32-bit form of an instruction, the upper 32 bits of the source registers are ignored and the upper 32 bits of the destination register are set to zero.

1 Like

Oh, Thanks very much, so it is depended on the register properties, and at least true for AArch64 target.