search for: dw_op_minus

...!dbg !31 ; Combine redundant instructions, "a" is salvaged... %call = call i32 @_Z3bazv(), !dbg !25 %call1 = call i32 @_Z3barv(), !dbg !26 %add = add nsw i32 %call, %call1, !dbg !27 call void @llvm.dbg.value(metadata i32 %add, metadata !24, metadata !DIExpression(DW_OP_constu, 4, DW_OP_minus, DW_OP_stack_value)), !dbg !28 %sub = shl i32 %add, 1, !dbg !29 %mul = add i32 %sub, -8, !dbg !29 ret i32 %mul, !dbg !30 ; bar() is found to always return 4 %call = call i32 @_Z3bazv(), !dbg !14 %add = add nsw i32 %call, 4, !dbg !15 call void @llvm.dbg.value(metadata i32 %add, metadata...

...no-op DIExpression reduction is unlikely to have a huge impact in itself, but having a "stack_value that could be an l-value" nicely rounds out the LLVM representation for debug values. >If we had DW_OP_LLVM_direct: what would be the semantics of > >DIExpression(DW_OP_constu, 4, DW_OP_minus, DW_OP_LLVM_direct) > >versus > >DIExpression(DW_OP_constu, 4, DW_OP_minus) ? Once we have the _direct operator, which will be used for all register locations and some implicit locations, we can safely say that any expression that isn't _direct, implicit, or empty will be a memory...

Hi Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of

Hi Vedant, thanks for the detailed response, On Tue, Feb 25, 2020 at 7:23 AM Vedant Kumar <vedant_kumar at apple.com> wrote: > > Finally, being forced to always specify both the machine location and > > the program location at the same time (in a single DBG_VALUE) > > introduces un-necessary burdens. In MachineSink, when we sink between > > blocks an instruction that

...b - 5; If both b and c are optimized out and salvaged, then we end up with the following dbg.values: @llvm.dbg.value(i32 %a, !"b", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_LLVM_direct)) @llvm.dbg.value(i32 %a, !"c", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_constu, 5, DW_OP_minus, DW_OP_LLVM_direct)) ; DIExpressions optimized... @llvm.dbg.value(i32 %a, !"b", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_LLVM_direct)) @llvm.dbg.value(i32 %a, !"c", !DIExpression(DW_OP_LLVM_direct)) In this admittedly strange case, we start with b and c as l-values...

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg