[DAGCombiner] `zext (trunc nuw nsw (x))` incorrectly optimized away

[dlee992]

💡 Example: Trunc + Zext in LLVM IR

The following function demonstrates a trunc followed by a zext:

define i64 @bar(i64 %a) {
; CHECK-LABEL: bar:
; CHECK:       ; %bb.0:
; CHECK-NEXT:    ret 0
  %trunc = trunc nuw nsw i64 %a to i32
  %res = zext i32 %trunc to i64
  ret i64 %res
}

Ideally, LLVM should emit code that preserves the lower 32 bits of %a and zeros out the upper 32 bits. However, in the latest LLVM, it appears this truncation + zero-extension is incorrectly optimized into a constant 0. Since it's a new feature, I am not sure what's the correct semantics of nuw/nsw in trunc instruction.

This behavior is likely a regression and may be closely related to the following patch:
👉 #113808

[dlee992]

This is a false alarm. The semantics of having nuw/nsw in trunc means the truncated bits (in this case, the upper 32 bits) are all zero, then it looks correct.

But in my another complex testcase, this DAGCombiner optimization indeed generates sub-optimal results for me. Will dig more to provide more feedback.