<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:607086046;
mso-list-type:hybrid;
mso-list-template-ids:1566991542 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:960766394;
mso-list-type:hybrid;
mso-list-template-ids:290251704 753329122 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1541551294;
mso-list-type:hybrid;
mso-list-template-ids:-101949150 1436187604 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.75in;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Dave,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Let me explain my point of view (apology for long mail)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The bigger goal is to enable debugger to be able to display value of as many variables as possible (in theory it can be ALL, practically it may be all important variables).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This can be achieved in multiple ways.<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Keeping the variable in memory<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">If optimized out, it can be represented as DWARF expressions (DW_OP_stack_value, DW_OP_lit0, DW_OP_piece).<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">If variable is optimized out but its value can be seen in other variable (statement ‘ptr=&obj’ implies (‘*ptr=obj’) that value contained by ‘ptr’ can be seen in ‘obj’) . This is done
using DW_OP_implicit_pointer. DW_OP_implicit pointer just tells that value can be implicitly checked in OTHER variable which is present. Its responsibility ends here, the value will be displayed ONLY if the OTHER variable has value (may be using DWARF expressions
as in way-2 above).<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Coming back to your test case. Thanks for sharing the test case.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If you notice for the same test case value is propagated to function ‘f’.<o:p></o:p></p>
<p class="MsoNormal">--------------- <o:p></o:p></p>
<p class="MsoNormal">__attribute__((optnone)) int source() {<o:p></o:p></p>
<p class="MsoNormal"> return 3;<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">__attribute__((optnone)) void f(int i) {<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">inline void sink(const int& p) {<o:p></o:p></p>
<p class="MsoNormal"> f(p);<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">int main() {<o:p></o:p></p>
<p class="MsoNormal"> sink(source());<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">------------ <o:p></o:p></p>
<p class="MsoNormal">With gdb <o:p></o:p></p>
<p class="MsoNormal">(gdb) bt<o:p></o:p></p>
<p class="MsoNormal">#0 f (i=3) at test1.cc:5<o:p></o:p></p>
<p class="MsoNormal">#1 0x00000000004004b0 in sink (p=<optimized out>) at test1.cc:7<o:p></o:p></p>
<p class="MsoNormal">#2 main () at test1.cc:10<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In this case though we are not able to check the variable in ‘sink’ but we can check it in ‘f’. As compiler decides it as non-important in sink while propagates it to ‘f’<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Lets change a little to test case.<o:p></o:p></p>
<p class="MsoNormal">---------------------- <o:p></o:p></p>
<p class="MsoNormal">__attribute__((optnone)) int source() {<o:p></o:p></p>
<p class="MsoNormal"> return 3;<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">__attribute__((optnone)) void f(const int& i) {<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">inline void sink(const int& p) {<o:p></o:p></p>
<p class="MsoNormal"> f(p);<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">int main() {<o:p></o:p></p>
<p class="MsoNormal"> sink(source());<o:p></o:p></p>
<p class="MsoNormal">}<o:p></o:p></p>
<p class="MsoNormal">----------------------- <o:p></o:p></p>
<p class="MsoNormal">#0 f (i=@0x7fffffffe3e4: 3) at test2.cc:5<o:p></o:p></p>
<p class="MsoNormal">#1 0x00000000004004b8 in sink (p=@0x7fffffffe3e4: 3) at test2.cc:7<o:p></o:p></p>
<p class="MsoNormal">#2 main () at test2.cc:10<o:p></o:p></p>
<p class="MsoNormal">----------------------- <o:p></o:p></p>
<p class="MsoNormal">In this case we can get the value of ‘p’ in ‘sink’ as well, and that happens because compiler considers it important and decides to keep the temporary (store to it).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">IMO the variable value not seen is corner case (it doesn’t apply to pointers, it applies to references only when it refers to a temporary and compiler does optimize that temporary). But even if we decide to get this case displayed, it comes
under bigger goal of displaying a variable value. We can solve this problem in many ways.<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:.25in;mso-list:l2 level1 lfo3">Way-1 above) Keeping the temporary (store to it). It is performance penalty compiler decides if variable is that important.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:.25in;mso-list:l2 level1 lfo3">Way-3 above) DW_OP_implicit_pointer is only implies/redirects a variable to something that is available in Dwarf, so ideally this case doesn’t fall under this. But yes to extend
it we can generate artificial DIE for temporary variable as suggested by Paul<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:.25in;mso-list:l2 level1 lfo3">Way-2 above) We can use any existing/new Dwarf expression to keep the value in variable itself.
<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">IMO since now DW_OP_implicit_pointer is part of standard. It will be good to comply. Moreover popular tool GNU gdb will work with it which would be added advantage. We can start with existing DW_OP_implicit_pointer, incrementally we can
increase the scope of bigger goal of displaying all the important variables (with/without help of implicit pointers). Thanks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Alok <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> David Blaikie <dblaikie@gmail.com> <br>
<b>Sent:</b> Friday, November 15, 2019 11:24 PM<br>
<b>To:</b> Robinson, Paul <paul.robinson@sony.com><br>
<b>Cc:</b> Adrian Prantl <aprantl@apple.com>; Sharma, Alok Kumar <AlokKumar.Sharma@amd.com>; Jonas Devlieghere <jdevlieghere@apple.com>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> Re: DW_OP_implicit_pointer design/implementation in general<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[CAUTION: External Email] <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Nov 15, 2019 at 8:07 AM Robinson, Paul <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">| Any ideas why it wouldn't be more general to handle cases where the variable isn't named?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Couldn’t there be a DIE (flagged as artificial) to describe the return-value temp?<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
There could be - though there are very few (the array bound example Adrian gave is the only one I know of - and even that seems unnecessary/GCC uses a different (& I think better/clearer/simpler) representation) cases of artificial variables being generated
in Clang/LLVM - it lacks precedent so far as I can tell.<br>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> You’d need such a DIE if you wanted the debugger to be able to look at the return value from source() anyway,<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><br>
Not so far as I know - with GDB (& I assume LLDB) when you call a function and return from it (eg: "finish" or "step" that steps across the end of a function) the debugger prints out the return value (using the DW_AT_type of the DW_TAG_subprogram that was executing
& its knowledge of the ABI to know where/how that value would be stored during the return) & you can actually then query it and do other things using the artificial variable name GDB provides<br>
<br>
(my example was slightly bogus - you can't take the address of a temporary in C++ like that, but you can take a reference to it, so updating & fleshing out the test:<br>
<br>
<span style="font-family:"Courier New"">__attribute__((optnone)) int source() {<br>
return 3;<br>
}<br>
__attribute__((optnone)) void f(int) {<br>
}<br>
inline void sink(const int& p) {<br>
f(p);<br>
}<br>
int main() {<br>
sink(source());<br>
}</span><br>
<br>
& then playing that through GDB:<br>
<span style="font-family:"Courier New""><br>
(gdb) start<br>
Temporary breakpoint 1 at 0x401131: file var.cpp, line 10.<br>
Starting program: /usr/local/google/home/blaikie/dev/scratch/a.out <br>
<br>
Temporary breakpoint 1, main () at var.cpp:10<br>
10 sink(source());<br>
(gdb) s<br>
source () at var.cpp:2<br>
2 return 3;<br>
(gdb) fin<br>
Run till exit from #0 source () at var.cpp:2<br>
main () at var.cpp:10<br>
10 sink(source());<br>
Value returned is $1 = 3<br>
(gdb) s<br>
sink (p=<optimized out>) at var.cpp:7<br>
7 f(p);</span><br>
<br>
It'd be nice if the value of 'p' could be printed there, but it seems without introducing artificial variables, the implicit_pointer doesn't provide a way to do that & that seems to me like an unnecessary limitation & complication in the DWARF and in LLVM's
intermediate representation compared to having 'p's DW_AT_location describe the value being pointed to directly without the need for another variable?<br>
<br>
- Dave<br>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">in the context of main() and in the absence of inlining. And given that DIE, implicit_pointer within sink() can refer to it.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, November 14, 2019 5:32 PM<br>
<b>To:</b> Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>><br>
<b>Cc:</b> Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>>;
<a href="mailto:AlokKumar.Sharma@amd.com" target="_blank">AlokKumar.Sharma@amd.com</a>; Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com" target="_blank">jdevlieghere@apple.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: DW_OP_implicit_pointer design/implementation in general<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Nov 14, 2019 at 1:53 PM Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My reading of the DWARF issue is that it was fairly specifically designed to handle the case of a function taking parameters by pointer/reference, which is then inlined, and the
caller is passing local objects rather than other pointers/references. So:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">void inline_me(foo *ptr) {<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> does something with ptr->x or *ptr;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">}<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">void caller() {<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> foo actual_obj;<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> inline_me(&actual_obj);<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">}<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">After inlining, maintaining a pointer to actual_obj might be sub-optimal, but after a “step in” to inline_me, the user wants to look at an expression spelled *ptr even though the
actual_obj might not have a memory address (because fields are SROA’d into registers, or whatever). This is where DW_OP_implicit_pointer saves the day; *ptr and ptr->x are still evaluatable expressions, which expressions are secretly indirecting through the
DIE for actual_obj.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think it is not widely applicable outside of that kind of scenario.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Any ideas why it wouldn't be more general to handle cases where the variable isn't named? Such as:<br>
<br>
foo source();<br>
void f(foo);<br>
inline void sink(foo* p) {<br>
f(*p);<br>
}<br>
int main() {<br>
sink(&source());<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--paulr<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>
<br>
<b>Sent:</b> Thursday, November 14, 2019 4:34 PM<br>
<b>To:</b> Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>><br>
<b>Cc:</b> <a href="mailto:AlokKumar.Sharma@amd.com" target="_blank">AlokKumar.Sharma@amd.com</a>; Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>>; Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com" target="_blank">jdevlieghere@apple.com</a>>;
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: DW_OP_implicit_pointer design/implementation in general<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br>
> On Nov 14, 2019, at 1:21 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
> Hey folks,<br>
> <br>
> Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure
I understand the motivation, exactly.<br>
> <br>
> The core point of my confusion: Why does describing the thing a pointer points to require describing a named variable that it points to? What if it doesn't point to a named variable?
<br>
<br>
Without having looked at the motivational text when the feature was proposed to DWARF, my assumption was that this is similar to how bounds for variable-length arrays are implemented, where a (potentially) artificial variable is created by the compiler in order
to have something to refer to.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
I /sort/ of see that case as a bit different, because the array type needs to refer back into the function potentially (to use frame-relative, etc). I could think of other ways to do that in hindsight (like putting the array type definition inside the function
to begin with & having the count describe the location directly, for instance).<br>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In retrospect I find the entire specification of DW_OP_implicit_pointer to be strangely specific/limited (why one hard-coded offset instead of an arbitrary expression?), but that
ship has sailed for DWARF 5 and I'm to blame for not voicing that concern earlier.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Sure, but we don't have to implement it if we don't find it to be super useful/worthwhile, right? (if something else would be particularly more general/useful we could instead implement
that as an extension, though of course there's cost to that in terms of consumer support, etc)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
<br>
-- adrian<br>
<br>
> <br>
> Seems like there should be a way to describe that situation - and that doing so would be a more general solution than one limited to only describing pointers that point to named variables. And would be a simpler implementation in LLVM - without having to
deconstruct variables during optimizations, etc, to track one variable's value being concretely related to another variable's value.<br>
> <br>
> - David<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>