<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 11/03/2017 05:26 PM, 陳韋任 via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CAFSLk9cr7eK+m6XK+464f4b79M7OpRTj1eJDGTOzZ70UwotrZg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-11-04 4:29 GMT+08:00 Kaylor,
Andrew 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>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_4695229196957410940WordSection1">
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">Copying the list on a
discussion of potentially general interest….</span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="m_4695229196957410940__MailEndCompose"><span
style="color:rgb(31,73,125)"> </span></a></p>
<div>
<div
style="border-right:none;border-bottom:none;border-left:none;border-top:1pt
solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Kaylor, Andrew <br>
<b>Sent:</b> Friday, November 03, 2017 1:11 PM<br>
<b>To:</b> 'Ding, Wei' <<a
moz-do-not-send="true"
href="mailto:Wei.Ding2@amd.com"
target="_blank">Wei.Ding2@amd.com</a>>;
Sumner, Brian <<a moz-do-not-send="true"
href="mailto:Brian.Sumner@amd.com"
target="_blank">Brian.Sumner@amd.com</a>>;
Arsenault, Matthew <<a moz-do-not-send="true"
href="mailto:Matthew.Arsenault@amd.com"
target="_blank">Matthew.Arsenault@amd.com</a>><br>
<b>Subject:</b> RE: clarification needed for the
constrained fp implementation.</p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">Hi Wei,</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">I’ve been meaning to
write something up for discussion on the LLVM Dev
list about this. I hope you don’t mind if I copy
the list now to accomplish that while also
answering your questions. Eventually I create a
document describing this in more detail and less
formally than the language definition.</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">Basically, the
“constraints” in the constrained FP intrinisics
are constraints on the optimizer. They are a way
of telling the optimizer what it can and cannot
assume about rounding mode and FP exception
behavior. By default, the optimizer assumes that
the rounding mode is round-to-nearest and that FP
exceptions are being ignored. If the user code is
going to do anything that invalidates these
assumptions, then we need a way to make the
optimizer stop assuming that. That’s what the
intrinisics do. Because most passes don’t
recognize the intrinisics, they can’t do anything
with the operations they represent and therefore
can’t make any assumption about them.</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">The intrinsics are
not intended to do anything to change the rounding
mode or FP exception handling state. I have an
idea in mind for some additional intrinsics that
would provide a way to control the FP
environment. There are already some
target-specific mechanisms for doing that, but I’d
like to have something that’s target independent.
I’ll say more about this in a minute.</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">I mentioned in my
review comments that my work on this has been
motivated by the STDC pragmas, and I think if I
explain that it might make the semantics of the
intrinsics seem a little more natural. The
primary pragma I have in mind here is the “STDC
FENV_ACCESS” pragma. I believe this is part of
the C99 standard, but compiler support for it is
still mostly (if not entirely) missing. For
instance, if you try to use this pragma with clang
you will get a message telling you that the pragma
isn’t supported and it will have no other effect.
We want to change that.</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">Basically, what the
“STDC FENV_ACCESS” pragma does is provide
programmers with a way to tell the compiler that
the program might change the FP environment. This
pragma represents a setting that has only two
states -- on and off. The default setting of this
state is documented as being implementation
defined. In clang the default state will be off.
The C99 standard states that accessing the FP
environment (testing FP status flags, changing FP
control modes, etc.) when FENV_ACCESS is off is
undefined behavior. The C99 standard provides
library calls to access the environment
(fesetround, fegetround, fetestexcept, etc.) but
you can only safely use these if you have set
FENV_ACCESS to the “on” state. A typical usage
might look like this:</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">#include
<fenv.h></span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">double
someFunc(double A, double B, bool ForceRoundUp) {</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> #pragma STDC
FENV_ACCESS ON</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> double Result;</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> if (ForceRoundUp) {</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> int OldRM =
fegetround();</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">
fesetround(FE_UPWARD);</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> Result = A/B;</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">
fesetround(OldRM);</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> } else {</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> Result = A/B;</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> }</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> return Result;</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">}</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><font color="#000000">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;display:inline">...
</div>
abridge
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;display:inline">
...</div>
</font></div>
<div><span style="color:rgb(221,75,57)"><br>
</span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_4695229196957410940WordSection1">
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"></span></p>
<p class="MsoNormal"><br>
</p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">What I’m thinking is
that we need something like this:</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">void
llvm.set.roundingmode(i32 mode)</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">i32
lllvm.get.roundingmode()</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">These would then get
translated during instruction selection to
target-specific instructions, which is equivalent
to what fesetround() and fegetround() do. But I
think it would also be useful to have something
like this:</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">void
llvm.begin.local.roundingmode(<wbr>i32 mode)</span></p>
<p class="MsoNormal"><span
style="color:rgb(31,73,125)">void
llvm.end.local.roundingmode()</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">A little
bit of curiously. What if user doesn't restore the OldRM
like this</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><br>
</div>
</div>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px"><span style="color:rgb(0,0,0)">double
someFunc(double A, double B, bool ForceRoundUp) {<br>
</span><span style="color:rgb(0,0,0)"> #pragma STDC
FENV_ACCESS ON<br>
</span><span style="color:rgb(0,0,0)"> double Result;<br>
</span><span style="color:rgb(0,0,0)"> if (ForceRoundUp) {<br>
</span><span style="color:rgb(0,0,0)"> int OldRM =
fegetround();<br>
</span><span style="color:rgb(0,0,0)">
fesetround(FE_UPWARD);<br>
</span><span style="color:rgb(0,0,0)"> Result = A/B;<br>
</span><span style="color:rgb(0,0,0)">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;display:inline">//
</div>
fesetround(OldRM);<br>
</span><span style="color:rgb(0,0,0)"> } else {<br>
</span><span style="color:rgb(0,0,0)"> Result = A/B;<br>
</span><span style="color:rgb(0,0,0)"> }<br>
</span><span style="color:rgb(0,0,0)"> return Result;</span>
<div class="gmail_extra">
<p class="MsoNormal"><font color="#000000">}</font></p>
</div>
</blockquote>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Are we
still going to generate <span
style="font-family:arial,sans-serif"><font
color="#000000">llvm.begin.local.roundingmode/</font></span><span
style="font-family:arial,sans-serif"><font
color="#000000">llvm.end.local.roundingmode?</font></span></div>
</div>
</div>
</div>
</blockquote>
<br>
I think that, however we do this, we'll need a way of dealing with
"live in" and "live out" FP-environment state. Moreover, any
external call can change these as well (unless we prove/know that it
doesn't). Translating these calls into intrinsics so that the
optimizer can reason about them seems like a reasonable plan.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAFSLk9cr7eK+m6XK+464f4b79M7OpRTj1eJDGTOzZ70UwotrZg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><span
style="font-family:arial,sans-serif"><font
color="#000000"><br>
</font></span></div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><span
style="font-family:arial,sans-serif"><font
color="#000000">Regards,</font></span></div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><span
style="font-family:arial,sans-serif"><font
color="#000000">chenwj</font></span></div>
<br>
</div>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>Wei-Ren Chen (陳韋任)<br>
Homepage: <a moz-do-not-send="true"
href="https://people.cs.nctu.edu.tw/%7Echenwj"
target="_blank">https://people.cs.nctu.edu.tw/~chenwj</a></div>
</div>
</div>
</div>
</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>