<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/27/2017 12:08 AM, Dan Gohman via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CACcSVPEeTSLsfG7Y0PzBAXC0Smgff4K+EOEDzcE0ZnD1VzbV4Q@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div>Hello,</div>
<div><br>
</div>
<div>This email picks up the thread that to my knowledge was
last discussed here:</div>
<div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html"
target="_blank">http://lists.llvm.org/pipermai<wbr>l/llvm-dev/2015-July/088103.<wbr>html</a></div>
</div>
<div><br>
</div>
<div>In brief, infinite loops containing no side effects produce
undefined behavior in C++ (and C in some cases), however in
other languages, they have fully defined behavior. LLVM's
optimizer currently assumes that infinite loops eventually
terminate in a few places, and will sometimes delete them in
practice. There is currently no clean way to opt out of this
behavior from languages where it's not valid.</div>
<div><br>
</div>
<div>This is the subject of a long-standing LLVM bug:<br>
</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=965"
target="_blank">https://bugs.llvm.org/show_bug<wbr>.cgi?id=965</a></div>
<div><br>
</div>
<div>I wrote a patch implementing Chandler's idea from the above
thread, @llvm.sideeffect, a new intrinsic which is a no-op
except that it tells the optimizer to behave as if there were
side effects present:<br>
</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://reviews.llvm.org/D38336" target="_blank">https://reviews.llvm.org/D3833<wbr>6</a></div>
<div><br>
</div>
<div>Similar results can be achieved with empty inline asms,
however they tend to pessimize optimizations. The patch above
allows all of the major optimizations to work in the presence
of @llvm.sideeffect.</div>
</div>
</blockquote>
<br>
I think that we should move forward with this approach (as may be
obvious given that I've okay'd the patch). It's a lightweight
solution, at least on LLVM's side of things, and does not prevent
other solutions later.<br>
<br>
<blockquote
cite="mid:CACcSVPEeTSLsfG7Y0PzBAXC0Smgff4K+EOEDzcE0ZnD1VzbV4Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>One of the concerns raised is that front-ends would have to
emit a lot of these intrinsics, potentially one in every loop,
one in every function (due to opportunistic tail-call
optimization), and one in front of every label reachable by
goto or similar, if a front-end can't determine when they
aren't needed.</div>
</div>
</blockquote>
<br>
This is a valid concern, however, I expect that most programs from
higher-level languages will have well-structured loops, and it will
be straightforward to emit the intrinsics.<br>
<br>
<blockquote
cite="mid:CACcSVPEeTSLsfG7Y0PzBAXC0Smgff4K+EOEDzcE0ZnD1VzbV4Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> This is indeed a downside. It's mitigated in this patch by
making sure that the major optimization passes aren't
pessimized.<br>
</div>
<div><br>
</div>
<div>
<div>From the alternatives I've read, the most promising
alternative is Reid's proposal here:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://bugs.llvm.org/show_bug.cgi?id=965#c25">https://bugs.llvm.org/show_bug.cgi?id=965#c25</a><br>
</div>
<div><br>
</div>
<div>to make infinite loops defined by default, and add a
"known to be productive" attribute to functions. It would be
a more complex change, and could potentially require changes
in out-of-tree codebases. And it would be suboptimal in some
cases when cross-language inlining. However, it would solve
the problem in a much less cluttered way. I'm willing to
implement the LLVM portion of this if there's consensus that
it's a better approach.<br>
</div>
</div>
</div>
</blockquote>
<br>
The problem is that it is not a function-level property, it is a
per-loop property. This is even true in C. In C, we would need to
mark loops that have source-level-constant controlling conditions,
and only those loops, and allowed to be infinite. And, so, maybe we
could use loop-level metadata, but that seems hard to place/preserve
for unstructured loops (and, arguably, that's more important in
C/C++ than in other languages).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CACcSVPEeTSLsfG7Y0PzBAXC0Smgff4K+EOEDzcE0ZnD1VzbV4Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thoughts?<br>
</div>
<div><br>
</div>
Dan<br>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>