[PATCH] D64595: [Debuginfo][SROA] Need to handle dbg.value in SROA pass.

Alexey Lapshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 22 01:32:12 PDT 2019


avl added a comment.

@jmorse

> Converting a dbg.value into a dbg.declare implicitly extends the duration ("lifetime" in the docs [0]) of the variable location from "until the next dbg.value" to "the entire scope". Consider what happens if we make the modifications here [1] to your test case. Imagine an IR producer that wants to temporarily bind some variable to a field of 'result' (the dbg.value added with DW_OP_deref), and later assigns '1' to the variable with the second dbg.value, to cover the rest of the function.

Agreed. Converting a dbg.value into a dbg.declare implicitly extends the duration of the variable location from "until the next dbg.value" to "the entire scope".

Though in this case, it looks like the scope of interest match with scope of dbg.declare for alloca load/stores and does not breake other non-memory values.

I updated a patch with a routine which refuses dbg.values which are not aggregate and do not have DW_OP_deref in expression.

previous version of the patch generates incorrect dbg.values intrinsics for above example. But the source of the problem here is not dbg.value->dbg.declare->dbg.value conversion by itself. The problem is in that there were used incorrect dbg.value as a source. Dbg.value for variable "bess", which is a pointer to "result", should be deleted(since the pointer is optimized out). Instead it was used to create dbg.declare. Which later converted to incorrect dbg.value :

  call void @llvm.dbg.value(metadata i32 %call, metadata !21, metadata !DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !25

New version of the patch implements checking expression for aggregate values and produces correct result for that test case:

  entry:
    %call = call i32 @_Z3foov(), !dbg !23
    call void @llvm.dbg.value(metadata i64 1, metadata !21, metadata !DIExpression()), !dbg !24
    call void @llvm.dbg.value(metadata i32 %call, metadata !12, metadata !DIExpression()), !dbg !25
    %cmp.i = icmp eq i32 %call, 0, !dbg !26
    br i1 %cmp.i, label %if.then, label %if.end, !dbg !33

All dbg.values which relate to variable but not affecting alloca would be preserved after dbg.value->dbg.declare->dbg.value conversion(like metadata i64 1, metadata !21). They just would not be taken into account by findDeclarations function. mem2reg conversion (which is done for alloca) do not breake them. Inserting dbg.declare allows to convert memory accesses by mem2reg later. Please check additional test case - llvm/test/DebugInfo/X86/sroa-after-inlining2.ll. all constant expressions are used correctly there.

Assuming all inserted dbg.declare would be converted out in mem2reg - that is probably OK to insert dbg.declare here and location intervals looks correct.

If that is not OK, then as an alternative there could be implemented inserting dbg.addr for corresponding dbg.values.

What do you think ?


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

https://reviews.llvm.org/D64595





More information about the llvm-commits mailing list