<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:"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.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-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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">Thanks for the input!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ve filed <a href="https://bugs.llvm.org/show_bug.cgi?id=43546">
https://bugs.llvm.org/show_bug.cgi?id=43546</a><o:p></o:p></p>
<p class="MsoNormal">There are other computed goto reported bugs, but they don’t seem related to this.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a name="_____replyseparator"></a><b>From:</b> James Y Knight <jyknight@google.com>
<br>
<b>Sent:</b> Thursday, October 3, 2019 10:01 AM<br>
<b>To:</b> De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan@intel.com><br>
<b>Cc:</b> cfe-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [cfe-dev] the "computed goto" problem<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Definitely a bug.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Looks like a bug in the combination of block addresses, constexpr, and lambda functions. Note that the "labels" global value gets duplicated -- one for the function it's defined in, and then a copy for the inner lambda function. The copy
for the lambda got the block references broken, by attempting to change the function the block is defined in, to the lambda. Obviously, those blocks don't actually exist within the lambda function, so that's busted!<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:teal">@__const._Z22run_with_computed_gotoPK8bytecode.labels =</span><span style="color:black">
</span><span style="color:blue">private</span><span style="color:black"> </span><span style="color:teal">unnamed_addr</span><span style="color:black">
</span><span style="color:teal">constant</span><span style="color:black"> [</span><span style="color:#09885A">3</span><span style="color:black">
</span><span style="color:teal">x</span><span style="color:black"> </span><span style="color:teal">i8</span><span style="color:black">*] [</span><span style="color:teal">i8</span><span style="color:black">*
</span><span style="color:teal">blockaddress</span><span style="color:black">(</span><span style="color:teal">@_Z22run_with_computed_gotoPK8bytecode</span><span style="color:black">,
</span><span style="color:#CD3131">%</span><span style="color:#09885A">9</span><span style="color:black">),
</span><span style="color:teal">i8</span><span style="color:black">* </span><span style="color:teal">blockaddress</span><span style="color:black">(</span><span style="color:teal">@_Z22run_with_computed_gotoPK8bytecode</span><span style="color:black">,
</span><span style="color:#CD3131">%</span><span style="color:#09885A">13</span><span style="color:black">),
</span><span style="color:teal">i8</span><span style="color:black">* </span><span style="color:teal">blockaddress</span><span style="color:black">(</span><span style="color:teal">@_Z22run_with_computed_gotoPK8bytecode</span><span style="color:black">,
</span><span style="color:#CD3131">%</span><span style="color:#09885A">17</span><span style="color:black">)],
</span><span style="color:teal">align</span><span style="color:black"> </span><span style="color:#09885A">16</span><span style="color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:teal">@__const._Z22run_with_computed_gotoPK8bytecode.labels.1 =</span><span style="color:black">
</span><span style="color:blue">private</span><span style="color:black"> </span><span style="color:teal">unnamed_addr</span><span style="color:black">
</span><span style="color:teal">constant</span><span style="color:black"> [</span><span style="color:#09885A">3</span><span style="color:black">
</span><span style="color:teal">x</span><span style="color:black"> </span><span style="color:teal">i8</span><span style="color:black">*] [</span><span style="color:teal">i8</span><span style="color:black">*
</span><span style="color:teal">blockaddress</span><span style="color:black">(</span><span style="color:teal">@</span><span style="color:#A31515">"_ZZ22run_with_computed_gotoPK8bytecodeENK3$_0clEv"</span><span style="color:black">, <</span><span style="color:teal">badref</span><span style="color:black">>),
</span><span style="color:teal">i8</span><span style="color:black">* </span><span style="color:teal">blockaddress</span><span style="color:black">(</span><span style="color:teal">@</span><span style="color:#A31515">"_ZZ22run_with_computed_gotoPK8bytecodeENK3$_0clEv"</span><span style="color:black">,
<</span><span style="color:teal">badref</span><span style="color:black">>), </span>
<span style="color:teal">i8</span><span style="color:black">* </span><span style="color:teal">blockaddress</span><span style="color:black">(</span><span style="color:teal">@</span><span style="color:#A31515">"_ZZ22run_with_computed_gotoPK8bytecodeENK3$_0clEv"</span><span style="color:black">,
<</span><span style="color:teal">badref</span><span style="color:black">>)], </span>
<span style="color:teal">align</span><span style="color:black"> </span><span style="color:#09885A">16</span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:black">If you want a workaround, I suggest not using the lambda. Changing it to e.g.<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:blue"> #define</span><span style="color:black"> next() labels[*instructions++]<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="background:#FFFFFE"><span style="color:black">should be fine.<o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Oct 3, 2019 at 8:48 AM De Azevedo Piovezan, Felipe via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</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">
<p class="MsoNormal">Hello cfe,<br>
<br>
This year at CppCon (<a href="https://www.youtube.com/watch?v=9cPU1NdsgDQ" target="_blank">https://www.youtube.com/watch?v=9cPU1NdsgDQ</a>), there was a funny talk about the use of what they called a "computed goto".<br>
I was playing around with the idea, and there might be something incorrect about the code generated by clang when constexpr is involved (starting with 9.0).<br>
<br>
The idea is this: the address of a bunch of labels are taken and stored into a table:<br>
<br>
enum bytecode : int8_t { add1, add2, halt };<br>
<br>
constexpr void* labels[] = {<br>
[bytecode::add1] = &&add1_label,<br>
[bytecode::add2] = &&add2_label,<br>
[bytecode::halt] = &&halt_label,<br>
};<br>
<br>
//labels defined here...<br>
<br>
However, this is the IR generated with -O0 -emit-llvm:<br>
<br>
@labels = private unnamed_addr constant [3 x i8*] [i8* blockaddress(@"label1", <badref>), i8* blockaddress(@"label2", <badref>), i8* blockaddress(@"label3", <badref>)], align 16<br>
<br>
Note the badrefs! Also, we generate a basic block with no predecessors:<br>
<br>
12: ; No predecessors!<br>
indirectbr i8* undef, [label <badref>, label <badref>, label <badref>]<br>
<br>
As such, as soon as we start optimizing, the whole function is optimized away.<br>
If we remove constexpr, however, everything seems sane. Godbolt link: <a href="https://godbolt.org/z/Anc9EI" target="_blank">
https://godbolt.org/z/Anc9EI</a><br>
<br>
Any insights on what might be happening here? I suspect a lot of people will play around with this construction just "for fun" and will encounter this.<br>
<br>
--<br>
Felipe<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>