<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 07:01 PM, Dan Gohman
wrote:<br>
</div>
<blockquote
cite="mid:CACcSVPEDWSq7+KBHuQs=QNZGPSmNNLbZYufOmrQdBjXT+sPNrw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 27, 2017 at 1:12 PM, Reid
Kleckner <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">On Fri, Oct
27, 2017 at 1:08 PM, Hal Finkel <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</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>
<p>On 10/27/2017 02:51 PM, Reid Kleckner
wrote:<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>Personally, I don't like the side
effect intrinsic.</div>
</div>
</blockquote>
<br>
</span> Understood. I also don't like the fact
that it will clutter the IR in many cases.<span><br>
<br>
<blockquote 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>
</span> 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.</div>
</blockquote>
<div><br>
</div>
</span>
<div>Maybe we should do both? If the intrinsic is a
special case, that seems fine. It's cheap.</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">As I understand it, part of the
function attribute proposal is to change the default semantics
of LLVM IR to have defined behavior on infinite loops, and
then add an attribute opting into potential-UB. So if we do
that, then the role of @llvm.sideeffect becomes a little
subtle -- it'd be a way for a frontend for a language like C
to opt into potential-UB for a function, but then opt out for
individual loops in that function. Is that what you're
proposing? If so, I'm ok taking that route.<br>
</div>
</div>
</blockquote>
<br>
That's my understanding of the proposal.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CACcSVPEDWSq7+KBHuQs=QNZGPSmNNLbZYufOmrQdBjXT+sPNrw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Dan</div>
<div class="gmail_extra"><br>
</div>
</div>
</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>