<div dir="ltr"><div dir="ltr"><div dir="ltr"><p class="MsoNormal">>====================<u></u><u></u></p><p class="MsoNormal">>Complex types<u></u><u></u></p><p class="MsoNormal">>====================<u></u><u></u></p><p class="MsoNormal">>There, I said it.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Oh hell yes!<br></p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 2, 2019 at 9:17 PM Kaylor, Andrew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_8504723472718028403WordSection1">
<p class="MsoNormal">Hi Michael,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks for raising this topic. I am very interested, but unfortunately I won’t be at EuroLLVM. Here are some things on my mind, roughly in order of how much time I’ve spent thinking about them:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Constrained intrinsics  <u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">This has been dragging on for a really long time now. I’m at least partially responsible for that as I got it started but haven’t had the time recently to respond quickly to the review request of other contributors. (My sincere apologies
 to those affected. I hope it is making its way back toward the top of my priority list.) I’d like to come up with a plan to get the initial implementation finished.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As Cameron mentioned there is a lot of work left to be done in terms of transferring the strict FP controls from IR to MIR across ISel. The current implementation basically punts and hopes for the best at that point. Ulrich Weigand submitted
 a patch, but it has been languishing in review for quite a long time. Honestly, I don’t know the ISel code well enough to evaluate his approach.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Besides the backend transition problems there is a lot of work to be done to teach existing optimizations to handle the constrained intrinsics. Also, something needs to be done in the front end to generate the intrinsics. A patch has been
 submitted to do something about this in IRBuilder, but I don’t believe anything has been done in the front end.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Precision modes<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Right now, we more-or-less support FLT_EVAL_METHOD=-1 when fast math is enabled and FLT_EVAL_METHOD=0 when we’re in precise mode. If we’re generating code for pre-SSE 32-bit Intel architecture we use FLT_EVAL_METHOD=2 instead. Other architectures
 may have similar variations. All of this is fine as default behavior, but I’d be interested in having the ability to explicitly specify FLT_EVAL_METHOD=1 and FLT_EVAL_METHOD=2. I believe this would primarily involve work in the front end(s).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">pragmas<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Related to the topic of finer grained control over FP optimizations, there are a slew of pragmas that would be nice to have. The most obvious one is FENV_ACCESS, which we’ve said is what the constrained intrinsics are driving toward. More
 recent standards proposals have added pragmas to locally declare rounding modes. Then there are a bunch of non-standard pragmas on my list that the Intel compiler supports to control FP optimizations. An example is float_control, which I believe we added for
 MSVC compatibility but also find useful on other platforms. I’d love to see support for things like this in clang.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Masked vector FP operations<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">We’ve resisted adding explicitly predicated operations other than load and store in the past, but I think for vector FP operations we’re going to need this in order to maintain strict FP semantics.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">SVML and other vector libraries<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">There is support in LLVM for generating calls to Intel’s Short Vector Math Library when code is vectorized. This probably needs to be more aware of various FP modes. I expect we’d like to support other libraries with similar needs.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Complex types<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">There, I said it.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Accuracy controls<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">We have a fast math flag that lets us substitute approximations for some math library functions. It would be nice to have a mechanism to control the accuracy of the approximations.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Per function controls<u></u><u></u></p>
<p class="MsoNormal">====================<u></u><u></u></p>
<p class="MsoNormal">Similarly, it would be nice to explicitly list which math library functions could be replaced.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’d also like to suggest the formation of a floating point working group to try to get more organized about driving some of these things (particularly the constrained intrinsics) toward completion.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Andy<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><a name="m_8504723472718028403______replyseparator"></a><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Michael Berg via llvm-dev<br>
<b>Sent:</b> Friday, March 29, 2019 10:05 AM<br>
<b>To:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> [llvm-dev] EuroLLVM Numerics issues<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">All:  There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization).<br>
<br>
Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog if
 you like for reference material:<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2019_03_llvm-2Dnumerics-2Dblog.html&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=lIxcsC2UyeGJi5Hn2huNzHXpqgf5OzZOf92RyNrXmJs&s=wCMWl0WYVSS4STsD_VcW77mg3aHBvei1BQTGnTgl9Rw&e=" target="_blank">http://blog.llvm.org/2019/03/llvm-numerics-blog.html</a><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">p.s. (restarting this thread here).<br>
<br>
Regards,<br>
Michael<u></u><u></u></p>
</div>
</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=lIxcsC2UyeGJi5Hn2huNzHXpqgf5OzZOf92RyNrXmJs&s=eT5NAwfcMF1MZh1ZXX0wwF3AMD2hFNllRAJS4Dd2wVU&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=lIxcsC2UyeGJi5Hn2huNzHXpqgf5OzZOf92RyNrXmJs&s=eT5NAwfcMF1MZh1ZXX0wwF3AMD2hFNllRAJS4Dd2wVU&e=</a><br>
</blockquote></div></div></div>