[X86] Add ISD::FREEZE and ISD::AssertAlign to the list of opcodes that don't guarantee upper 32 bits are zero.

[craig.topper]

Summary

The freeze issue was reported here
https://llvm.discourse.group/t/bug-or-feature-freeze-instruction/3639

I don't have a test for AssertAlign. I just noticed it was missing
and assume it should be similar to the other two Asserts.

[RKSimon]

LGTM - does this need to be back ported to 12.x?

[pengfei]

llvm/lib/Target/X86/X86InstrCompiler.td

1355–1358

Nit: Should add comments for AssertAlign and FREEZE?

[craig.topper]

In D104178#2815069, @RKSimon wrote:

LGTM - does this need to be back ported to 12.x?

Merge request filed as PR50695

llvm/lib/Target/X86/X86InstrCompiler.td

 def anyext_sdiv : PatFrag<(ops node:$lhs), (anyext node:$lhs),[{
   return (N->getOperand(0).getOpcode() == ISD::SDIVREM &&
           N->getOperand(0).getResNo() == 1);
 }]>;
 def : Pat<(i32 (anyext_sdiv GR8:$src)), (MOVSX32rr8 GR8:$src)>;
 
 // Any instruction that defines a 32-bit result leaves the high half of the
 // register. Truncate can be lowered to EXTRACT_SUBREG. CopyFromReg may
-// be copying from a truncate. Any other 32-bit operation will zero-extend
-// up to 64 bits. AssertSext/AssertZext aren't saying anything about the upper
-// 32 bits, they're probably just qualifying a CopyFromReg.
+// be copying from a truncate. AssertSext/AssertZext/AssertAlign aren't saying
+// anything about the upper 32 bits, they're probably just qualifying a
+// CopyFromReg. FREEZE may be coming from a a truncate. Any other 32-bit
+// operation will zero-extend up to 64 bits.
 def def32 : PatLeaf<(i32 GR32:$src), [{
   return N->getOpcode() != ISD::TRUNCATE &&
          N->getOpcode() != TargetOpcode::EXTRACT_SUBREG &&
          N->getOpcode() != ISD::CopyFromReg &&
          N->getOpcode() != ISD::AssertSext &&
-         N->getOpcode() != ISD::AssertZext;
+         N->getOpcode() != ISD::AssertZext &&
+         N->getOpcode() != ISD::AssertAlign &&
+         N->getOpcode() != ISD::FREEZE;
 }]>;
 
 // 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), GR32:$src, sub_32bit)>;
 def : Pat<(i64 (and (anyext def32:$src), 0x00000000FFFFFFFF)),
           (SUBREG_TO_REG (i64 0), GR32:$src, sub_32bit)>;

llvm/test/CodeGen/X86/freeze.ll

 ; X86ASM-NEXT:    addq %rax, %rax
 ; X86ASM-NEXT:    retq
   %y1 = freeze [2 x i64] undef
   %v1 = extractvalue [2 x i64] %y1, 0
   %v2 = extractvalue [2 x i64] %y1, 1
   %t1 = add i64 %v1, %v2
   ret i64 %t1
 }
+
+; Make sure we emit a movl to zext the input before the imulq. This previously
+; failed because freeze was not listed in the instructions that don't zext their
+; result in the def32 pattern X86InstrCompiler.td.
+define i32 @freeze_zext(i64 %a) nounwind {
+; X86ASM-LABEL: freeze_zext:
+; X86ASM:       # %bb.0: # %entry
+; X86ASM-NEXT:    movq %rdi, %rax
+; X86ASM-NEXT:    movl %eax, %ecx
+; X86ASM-NEXT:    movl $3435973837, %edx # imm = 0xCCCCCCCD
+; X86ASM-NEXT:    imulq %rcx, %rdx
+; X86ASM-NEXT:    shrq $35, %rdx
+; X86ASM-NEXT:    addl %edx, %edx
+; X86ASM-NEXT:    leal (%rdx,%rdx,4), %ecx
+; X86ASM-NEXT:    subl %ecx, %eax
+; X86ASM-NEXT:    # kill: def $eax killed $eax killed $rax
+; X86ASM-NEXT:    retq
+entry:
+  %x = trunc i64 %a to i32
+  %y = freeze i32 %x
+  %z = urem i32 %y, 10
+  ret i32 %z
+}