<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 2, 2020, at 7:01 AM, Tozer, Stephen <<a href="mailto:stephen.tozer@sony.com" class="">stephen.tozer@sony.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13px;" class=""></div><blockquote type="cite" class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13px;" class="">><font size="2" class="" style="font-size: 10px;"><span style="font-size: 11.666666984558105px;" class=""><span class="Apple-converted-space"> </span>I'm not sure this will work as stated here. Indirectness is (mostly) orthogonal to DW_OP_stack_value. DW_OP_stack_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we want something like DW_OP_deref instead, at least for r-values. For l-values (=variables a debugger could write to) we would need to have a discriminator that declares the DBG_VALUE as a memory location (cf. DWARF5 chapter 2.6).</span></font><br class=""></div></blockquote><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13px;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class="">This is a tricky one. Right now, DIExpressions sort-of mimic DWARF, but with differences that aren't always immediately clear. The reason why I chose DW_OP_stack_value for the direct-value-case instead of using DW_OP_deref for the indirect-value-case is that it is more like actual DWARF: a DWARF expression is either empty, a register, a memory address, or an implicit location.</div></div></blockquote><div><br class=""></div><div>Yeah, because that decision can only be made much later in LLVM in AsmPrinter/DwarfExpression.cpp.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class=""> The new representation handles each of these faithfully to DWARF, except for being unable to distinguish between the register and memory case for a single register argument. In DWARF, the difference is that a register location uses `<span style="font-family: Consolas, Courier, monospace;" class="">DW_OP_reg N</span>`, while any reference to a register's value in any other type of location uses `<span style="font-family: Consolas, Courier, monospace;" class="">DW_OP_breg N</span>`. We cannot specify these in LLVM since we only generate these operators at the end; previously, this was the job of the indirectness flag.</div></div></blockquote><div><br class=""></div><div>In DWARF, DW_OP_reg(x) is a register l-value, all others can either be l-values or r-values depending on whether there is a DW_OP_stack_value/DW_OP_implicit* at the end. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class="">Rather than reintroducing a flag just for this purpose however, I instead propose that we treat this as a special (albeit common) case: we can use `<span style="font-family: Consolas, Courier, monospace;" class="">DW_OP_LLVM_arg 0, DW_OP_stack_value</span>` with a single register operand. </div></div></blockquote><div><br class=""></div><div>I think it would be confusing to talk about registers at the LLVM IR / DIExpression level. "SSA-Values"?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class="">We already reduce the DIExpression to specialized DWARF operators at the point of DWARF emission, for example:<span class="Apple-converted-space"> </span><span style="font-family: Consolas, Courier, monospace;" class="">`<Register N>, DW_OP_plus_uconst 5</span>` becomes `<span style="font-family: Consolas, Courier, monospace;" class="">DW_OP_bregN RSP+5</span>`. If in any case where a stack value expression consists of only a single register it is valid to convert it to a register location, </div></div></blockquote><div><br class=""></div><div>I don't think that's correct, because a DW_OP_stack_value is an rvalue. But maybe I misunderstood what you were trying to say.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class="">then this should be a valid transformation; I can't think of any cases where it wouldn't be, since if we get a variable's value directly from a single register then it necessarily exists at that location. The only exception would be where, for one reason or another, we want DWARF to believe that the location is implicit and thus cannot be written to; if such a case exists then it might be suitable grounds to change the behaviour here.</div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class=""><br class=""></div><div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif;" class="">This does have the potential to cause confusion to a reader unfamiliar with this behaviour, but for a reader examining debug info in enough detail that the removal of DW_OP_stack_value raises an eyebrows, I think simply noting the behaviour in code comments and the documentation would be sufficient.</div></div></blockquote><br class=""></div><div>We should start be defining what DW_OP_stack_value really means in LLVM debug info metadata. I believe it should just mean "r-value".</div><div><br class=""></div><div>-- adrian</div></body></html>