[PATCH] D80034: [Local] Do not ignore zexts in salvageDebugInfo, PR45923

[Vedant Kumar via Phabricator via llvm-commits]

vsk added subscribers: JDevlieghere, debug-info.
vsk marked an inline comment as done.
vsk added inline comments.


================
Comment at: llvm/test/Transforms/InstCombine/cast-mul-select.ll:178
 ; DBGINFO-LABEL: @foo(
-; DBGINFO-NEXT:  call void @llvm.dbg.value(metadata i1 %b
+; DBGINFO-NEXT:  call void @llvm.dbg.value(metadata i1 %b, {{.*}} !DIExpression(DW_OP_LLVM_convert, 1, DW_ATE_unsigned, DW_OP_LLVM_convert, 8, DW_ATE_unsigned, DW_OP_stack_value))
 ; DBGINFO-NEXT:  ret i1 %b
----------------
aprantl wrote:
> I have not thought about the exact semantics, but I'm wondering if it would be possible to contract a sequence on DW_OP_convert operations in the backend in DwarfExpression.cpp to have a smaller encoding? I guess this would be easier if we distinguished between extending and truncating a value in our IR. Perhaps we'd need to introduce DW_OP_LLVM_zext & friends?
Yeah, we could try to simplify dwarf expressions really late in the backend, and/or do something like DW_OP_LLVM_zext to avoid emitting silly expressions in the first place.  The former might allow us to compact-ify dwarf in more cases where there's emergent complexity in the expression, but is also quite possibly overkill (cc @JDevlieghere). We should probably look at what kind of expressions actually pop out of a stage2 build, then figure out where (if anywhere) we ought to make things more compact.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80034/new/

https://reviews.llvm.org/D80034