<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>When I worked on debugging optimized code technology at DEC
(Digital Equipment Corporation for those old enough to recall)
back in the late 90's, it became clear that simply picking and
choosing optimizations as a way to get sorta decent code and sorta
decent debugability is a losing game that by itself can not
satisfy either goal particularly well. What is needed is a more
fundamental analysis of the optimized code as part of generating
the debugging information.</p>
<p>We dealt well, I think, with three difficult optimization
challenges:</p>
<ol>
<li>Split lifetime variables (plus value propagation)<br>
</li>
<li>Breakpoints and stepping based on semantic events in the
program</li>
<li>Function inlining</li>
</ol>
<p>A key premise what that this technology had to work without any
limitation on optimization. And it did!<br>
</p>
<p>A thorough overview of that work was published in "Debugging
Optimized Code: Concepts and Implementation on DIGITAL Alpha
Systems", Digital Technical Journal, Vol 10, No 1, pp81-99. That
journal was probably obscure even at the time, but it is readily
available at</p>
<p> <a
href="http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v10-01_1998.pdf">http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v10-01_1998.pdf</a></p>
<p>While the original work was performed for OpenVMS on Alpha, most
of it was later adapted to DEC's UNIX systems via the ladebug
debugger of the time, and even later much was also ported to
OpenVMS on Itanium (I64). <br>
</p>
<p>The bottom line is this: a combination of decent code and decent
debugability (-O1 -Og or even -O2 -G) is definitely achievable but
it takes more than just tinkering with optimization levels or
selective optimization.<br>
</p>
<p>Ron</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/29/2019 10:10 AM, John Reagan via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8b9ff649-0871-ea9d-6fd9-ac13622bb68b@vmssoftware.com">
<pre class="moz-quote-pre" wrap="">When I worked on the HPE NonStop compilers for x86 (we used Open64, not
LLVM), we adjusted our -O1 to make sure the source display didn't
"bounce around" based on feedback from users. We disabled any
optimization that would move things across statement boundaries. We
also disabled/de-tuned dead store since our DWARF location list support
was pretty basic and with the removed store, you'd get the "wrong"
answer when you did an examine. We weren't able at the time (they might
have improved since then) to always trim the location lists to create
the "dead zones".
We didn't create an -Og since the NonStop users were already used to
having -O1 be different from each prior platform (Itanium, MIPS, etc).
Personally, I would have liked an -Og since I think the name "feels" better.
For our OpenVMS compilers, we also settled on -O1 (/OPT=LEVEL=1 in DCL
speak) for "do whatever you think that won't mess up debugging". And
our -O0 still does some basic optimizations (ie, 1+1, if false, etc)
We didn't get much push back on performance between -O1 and the next
higher setting.
I'll be sure to look for Greg's round table
John
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Ron Brender
Whose favorite airplane is N6119A, a 1979 Cessna T210.</pre>
</body>
</html>