<div dir="ltr"><div dir="ltr">
> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt?<br>
</div><div dir="ltr"><br></div><div>Below is what I think for each suggestion.</div><div><br></div><div>
DW_OP_LLVM_implicit_pointer</div><div></div><div> * This is a good suggestion to include that in LLVM IR, because representation and specification (types of operands) of it a bit different that actual dwarf expression
DW_OP_LLVM_implicit_pointer. while creating actual dwarf info it will be converted to
DW_OP_LLVM_implicit_pointer.
This is implemented and patch is updated for it.</div><div>
</div><div dir="ltr">
DW_OP_LLVM_arg0 <br></div><div dir="ltr"></div><div> * This is good suggestion and will help in readability. It is also implemented and is available in updated patch.</div><div><br></div><div>Splitting dbg.value</div><div></div><div> * This is also a good idea from readability point of view. It also opens possibility of extension below is explanation.</div><div> </div><div>Since dbg.value currently represents (VAR=VALUE), the new intrinsic dbg.deref_value will represent de-referenced value (*VAR = VAL)</div><div></div><div> - Below represents ptr=null</div><div> call void @llvm.dbg.value(metadata i32* null, metadata !21, metadata !DIExpression())</div><div></div><div> - And below represents *ptr=var</div><div> call void @llvm.dbg.deref.value(metadata !16, metadata !21, metadata !DIExpression(DW_OP_LLVM_implicit_pointer, DW_OP_LLVM_arg0, 0))</div><div> - And below represents *ptr=arr[1]<br></div><div>
call void @llvm.dbg.deref.value(metadata !16, metadata !21, metadata !DIExpression(DW_OP_LLVM_implicit_pointer, DW_OP_LLVM_arg0, 4))</div><div>With this new representation we should be able to represent the case mentioned by David (in LLVM IR, we would still need some Dwarf operator to be understood by LLDB) when a variable points to temporary (initialized by constant) and temporary is optimized out.<br></div><div> tmp=[CONST]; ptr=&tmp;</div><div>
call void @llvm.dbg.deref.value(metadata [const], metadata !21, metadata !DIExpression(DW_OP_LLVM_arg0))</div><div>I shall update my patch with introduction of dbg.deref_value. Please do review.</div><div><br></div><div>Variadic dbg.value</div><div> It is also a good idea. But since no immediate benefit seem to be availed by implicit pointer, it can be done independently.</div><div><br></div><div>Regards,</div><div>Alok<br></div><div><br>
</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2019 at 5:23 AM Vedant Kumar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Nov 19, 2019, at 9:41 AM, Adrian Prantl via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> <br>
> <br>
>> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <<a href="mailto:jeremy.morse.llvm@gmail.com" target="_blank">jeremy.morse.llvm@gmail.com</a>> wrote:<br>
>> <br>
>> Hi llvm-dev@,<br>
>> <br>
>> Switching focus to the LLVM implementation, the significant change is<br>
>> using dbg.value's first operand to refer to a DILocalVariable, rather<br>
>> than a Value. There's some impedance mismatch here, because all the<br>
>> documentation (for example in the DbgVariableIntrinsic class)<br>
>> expresses everything in terms of the variables location, whereas<br>
>> implicit pointers don't have a location as they represent an extra<br>
>> level of indirection. This is best demonstrated by the change to<br>
>> IntrinsicInst.cpp in this patch [0] -- calling getVariableLocation on<br>
>> any normal dbg.value will return the locations Value, but if it's an<br>
>> implicit pointer then you'll get the meaningless MetadataAsValue<br>
>> wrapper back instead. This isn't the variable location, might surprise<br>
>> existing handlers of dbg.values, and just seems a little off.<br>
>> <br>
>> I can see why this route has been taken, but by putting a non-Value in<br>
>> dbg.value's, it really changes what dbg.values represent, a variable<br>
>> location in the IR. Is there any appetite out there for using a<br>
>> different intrinsic, something like 'dbg.loc.implicit', instead of<br>
>> using dbg.value? IMO it would be worthwhile to separate:<br>
>> * Debug intrinsics where their position in the IR is important, from<br>
>> * Debug intrinsics where both their position in the IR, _and_ a Value<br>
>> in the IR, are important.<br>
>> Of which (I think) implicit pointers are the former, and current [2]<br>
>> dbg.values are the latter. This would also avoid putting<br>
>> DW_OP_implicit_pointer into expressions in the IR, pre-isel at least.<br>
>> <br>
> <br>
> <br>
> On that particular point, I would like to see is a generalization of dbg.value: Currently llvm.dbg.value binds an SSA value (including constants and undef) and a DIExpression to a DILocalVariable at a position in the instruction stream. That first SSA value argument is an implicit first element in the DIExpression.<br>
> <br>
> A more general form would be a more printf-like signature:<br>
> <br>
> llvm.dbg.value(DILocalVariable, DIExpression, ...)<br>
> <br>
> for example<br>
> <br>
> llvm.dbg.value_new(DILocalVariable("x"), DIExpression(DW_OP_LLVM_arg0), %x)<br>
> llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus),<br>
> %ptr, %ofs)<br>
> llvm.dbg.value_new(DILocalVariable("z"), DIExpression(DW_OP_implicit_pointer, DW_OP_LLVM_arg0, 32),<br>
> DILocalVariable("base"))<br>
> llvm.dbg.value_new(DILocalVariable("c"), DIExpression(DW_OP_constu, 1))<br>
> <br>
> The mandatory arguments would be the variable and the expression, and an arbitrary number of SSA values and potentially other variables.<br>
<br>
I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt?<br>
<br>
vedant<br>
<br>
> <br>
> <br>
> As far as DW_OP_LLVM_implicit_pointer in particular is concerned, we could also treat the peculiarities of DW_OP_implicit_pointer as a DWARF implementation detail, introduce DW_OP_LLVM_implicit_pointer which transforms the top-of-stack into an implicit pointer (similar to DW_OP_stack_value) and have the DWARF backend insert an artificial variable on the fly.<br>
> <br>
> LLVM IR:<br>
> <br>
> llvm.dbg.value(%base, DILocalVariable("z"), DIExpression(DW_OP_LLVM_implicit_pointer))<br>
> <br>
> AsmPrinter would expand this into two DW_TAG_variable tags with one location (list) entry each.<br>
> <br>
> -- adrian<br>
> <br>
>> There's also Vedants suggestion [1] for linking implicit pointer<br>
>> locations with the dbg.values of the underlying DILocalVariable. I<br>
>> suspect the presence of control flow might make it difficult (there's<br>
>> no dbg.phi instruction), but I like the idea of having more explicit<br>
>> links in the IR, it would be much clearer to interpret what's going<br>
>> on.<br>
>> <br>
>> [0] <a href="https://reviews.llvm.org/D69999?id=229790" rel="noreferrer" target="_blank">https://reviews.llvm.org/D69999?id=229790</a><br>
>> [1] <a href="https://reviews.llvm.org/D69886#1736182" rel="noreferrer" target="_blank">https://reviews.llvm.org/D69886#1736182</a><br>
>> [2] Technically dbg.value(undef,...) is the former too, I guess.<br>
>> <br>
>> --<br>
>> Thanks,<br>
>> Jeremy<br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>