[llvm-dev] [RFC] Allowing debug intrinsics to reference multiple SSA Values

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 20 11:56:43 PST 2020


Great! This seems like a crucial feature for building expressions to
represent induction variables, which I am told is an important long
standing problem. From your proposed solutions, I like the idea of making
dbg.value variadic.

In the long run, I think we should consider making llvm.dbg.value a first
class IR instruction. My reasons for that mostly have to do with
efficiency, which doesn't relate to what you are doing, so I deleted what I
wrote on that topic to avoid derailing. I think using a variadic intrinsic
is consistent with this long-term design idea, to be discussed further at
another time.

On Thu, Feb 20, 2020 at 8:55 AM Tozer, Stephen via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Currently, the debug intrinsic functions each have 3 arguments: an SSA
> value representing either the address or Value of a local variable, a
> DILocalVariable, and a complex expression. If the SSA value is an
> Instruction, and that Instruction is at some point deleted, we attempt to
> salvage the SSA value by recreating the instruction within the complex
> expression. If the instruction cannot be replicated by a complex
> expression, then the variable location is dropped causing a reduction in
> coverage. One of the key restrictions on this process at the moment is that
> each intrinsic can only reference a single SSA value; a numeric constant
> may be represented within the expression itself, allowing for binary
> operators with a constant operand to be salvaged:
>
>
>
> %c = add i32 %a, 4
>
> llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression())
>
> ; Salvage...
>
> llvm.dbg.value(metadata i32 %a, DILocalVariable("x"),
> DIExpression(DW_OP_constu, 4, DW_OP_plus))
>
>
>
> This proposal is to allow multiple SSA value references within a debug
> intrinsic, allowing binary operators with non-constant operands to be
> salvaged. This is a long-awaited feature, with an open bugzilla[0] and
> support from members of the community[1][2]. To implement this change, each
> debug intrinsic will contain a list of SSA values instead of just one, and
> a new operator will be added: DW_OP_LLVM_register, which takes as its
> only argument the index of an SSA value within the intrinsic’s list, and
> pushes that SSA value onto the expression stack. Two proposed syntaxes for
> the list of SSA values - though suitable alternatives may be worth
> considering - are to either replace the first argument of the intrinsic
> function with an MDNode containing the SSA values as operands, or to remove
> the first argument and make the intrinsic function variadic, passing the
> SSA value list as vargs:
>
>
>
> %c = add i32 %a, %b
>
> llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression())
>
> ; Salvage...
>
> llvm.dbg.value(!{metadata i32 %a, metadata i32 %b}, DILocalVariable("x"),
> DIExpression(DW_OP_LLVM_register, 0, DW_OP_LLVM_register, 1, DW_OP_plus))
>
> ; Alternatively, the intrinsic function could be made variadic...
>
> llvm.dbg.value(DILocalVariable("x"), DIExpression(DW_OP_LLVM_register, 0,
> DW_OP_LLVM_register, 1, DW_OP_plus), metadata i32 %a, metadata i32 %b)
>
>
>
> The new operator DW_OP_LLVM_register would exist in the IR and MIR, and
> further down the pipeline be replaced by the appropriate operator for the
> target debug output. For example, when producing DWARF this would be
> replaced by DW_OP_regval_type, which pushes the contents of a given
> register interpreted as a value of a given type onto the DWARF expression
> stack.
>
>
>
> This has the potential to allow salvaging in a much greater number of
> cases than is currently possible. There are also potential follow-up tasks,
> such as allowing the salvaging of conditional values, that would further
> improve debug variable availability. The following table gives, for several
> of the multi-source application projects in the test suite, the number of
> successful invocations of SalvageDebugInfo, and the number of failed
> salvages for each type of unsalvageable instruction:
>
>
>
>             Success             Variadic Binops     Variadic GEPs
> Cmp Insts           Select Insts        Load Insts          Phi
> Nodes           Alloca Insts        Call Insts
>
> ALAC        261                 29                  61
> 0                   0                   1
> 12                  0                   0
>
> Burg        50                  1                   9
> 0                   1                   95
>  6                   0                   0
>
> hbd         514                 16                  1
> 0                   3                   45
> 10                  0                   4
>
> Lua         270                 12                  54
> 0                   12                  46
> 32                  1                   0
>
> minisat     458                 10                  10
> 3                   1                   35
>            4                   0                   0
>
> sgefa       439                 1                   121
> 0                   20                  14
> 55                  0                   0
>
> SIBsim4     153                 15                  6
> 0                   3                   40
> 3                   0                   0
>
> siod        112                 2                   1
> 0                   0                   11
> 5                   2                   1
>
> SPASS       1241                70                  27
> 27                  27                  2114
> 156                 0                   7
>
> spiff       39                  0                   15
> 0                   0                   7
> 2                   1                   0
>
> sqlite3     2322                94                  167
> 6                   37                  1143
> 136                 4                   10
>
> treecc      127                 1                   0
> 0                   1                   350
> 37                  0                   1
>
> viterbi     7                   0                   1
> 0                   1                   1
> 0                   0                   0
>
>
>
>
>
> Of these categories, the first 3 will become salvageable after this work
> is implemented, and Select Insts will also be salvageable with some
> follow-up work to enable conditional branching in complex expressions. The
> remainder are not salvageable in general, although it's possible that the
> specific passes that delete those instructions may be able to preserve the
> debug info as long as the code isn't totally dead.
>
>
>
> [0] https://bugs.llvm.org/show_bug.cgi?id=39141
>
> [1] https://reviews.llvm.org/D51976#1237060
>
> [2] http://lists.llvm.org/pipermail/llvm-dev/2019-November/137021.html
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200220/1b9140de/attachment.html>


More information about the llvm-dev mailing list