<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 02:51 PM, Reid Kleckner
wrote:<br>
</div>
<blockquote
cite="mid:CACs=tyJd5ipPvbgzxTXdvJ3zy_b9=G5+D8bNzLjr8mExneXWpg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div>Personally, I don't like the side effect intrinsic.</div>
</div>
</blockquote>
<br>
Understood. I also don't like the fact that it will clutter the IR
in many cases.<br>
<br>
<blockquote
cite="mid:CACs=tyJd5ipPvbgzxTXdvJ3zy_b9=G5+D8bNzLjr8mExneXWpg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div> 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>
</blockquote>
<br>
As I said below, a function attribute is insufficient. It needs to
be something we can mark per loop. This is needed to correctly model
C. The sideeffect intrinsic is the best proposal I've seen so far.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CACs=tyJd5ipPvbgzxTXdvJ3zy_b9=G5+D8bNzLjr8mExneXWpg@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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 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.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 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>
</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 moz-do-not-send="true"
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 moz-do-not-send="true" class="m_7751873471475328139moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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>
</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>
______________________________<wbr>_________________
LLVM Developers mailing list
<a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" 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>
</blockquote></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre></body></html>