[llvm] [InstCombine] Call InstSimplify for cast instructions (PR #162849)

Jeremy Morse via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 15 08:03:59 PDT 2025


================
@@ -11,10 +11,8 @@ define i16 @test5(i16 %A) !dbg !34 {
   call void @llvm.dbg.value(metadata i32 %C, metadata !37, metadata !DIExpression()), !dbg !41
 
   ; Preserve the dbg.value for the DCE'd 32-bit 'and'.
-  ;
-  ; The high 16 bits of the original 'and' require sign-extending the new 16-bit and:
   ; CHECK-NEXT: #dbg_value(i16 [[and]], [[C:![0-9]+]],
-  ; CHECK-SAME:    !DIExpression(DW_OP_LLVM_convert, 16, DW_ATE_signed, DW_OP_LLVM_convert, 32, DW_ATE_signed, DW_OP_stack_value)
+  ; CHECK-SAME:    !DIExpression(DW_OP_LLVM_convert, 16, DW_ATE_unsigned, DW_OP_LLVM_convert, 32, DW_ATE_unsigned, DW_OP_stack_value)
----------------
jmorse wrote:

Uurgh. This is similar to #151225, there's no strong typing of dbg.value operands, and so the transformation of IR Values sometimes isn't observed by any debug-info code (or: isn't always accounted for).

I don't think we really have a solid answer for what should happen here: is the sign-extend to produce a Value for an unsigned variable meaningful, or just an artifact of optimisation? CC @slinder1 on the topic of typed DIExpressions again.

IMO we're best off just letting this slide for now (land the patch, raise an issue?) because it's just as likely that the existing behaviour is unexpected as the new behaviour, and it shouldn't block better optimisations.

https://github.com/llvm/llvm-project/pull/162849


More information about the llvm-commits mailing list