<div dir="ltr"><div>Personally, I don't like the side effect intrinsic. It will pollute all the IR generated by non-C frontends. What most of these frontends really want is just a switch to disable a targeted set of optimizations.</div><div><br></div>One thing I like about the function attribute idea is that it's conservatively correct to discard it when doing cross-language inlining. It just becomes something that C-family frontends need to remember to add to enable their special-case language rules, rather than something that non-C languages need to think about. Similar to the 'access', builtin vs nonbuiltin discussion happening in parallel, the attribute enables the optimization, rather than inhibiting it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 12:37 PM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<p><br>
</p>
<div class="m_7751873471475328139moz-cite-prefix">On 10/27/2017 12:08 AM, Dan Gohman via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<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 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.ht<wbr>ml</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 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 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></span>
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.<span class=""><br>
<br>
<blockquote 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></span>
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.<span class=""><br>
<br>
<blockquote 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 href="https://bugs.llvm.org/show_bug.cgi?id=965#c25" target="_blank">https://bugs.llvm.org/show_<wbr>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></span>
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<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thoughts?<br>
</div>
<div><br>
</div>
Dan<br>
<br>
</div>
<br>
<fieldset class="m_7751873471475328139mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_7751873471475328139moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_7751873471475328139moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</span><span class="HOEnZb"><font color="#888888"><pre class="m_7751873471475328139moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</font></span></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>