<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Mar 8, 2019 at 12:43 PM Dallman, John <<a href="mailto:john.dallman@siemens.com">john.dallman@siemens.com</a>> wrote:<br></div><div class="gmail_quote"><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-GB">
<div class="gmail-m_-8400753106683368322WordSection1">
<p class="MsoNormal">Cameron wrote: <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">> The X86 backend has not been made trap-safe yet. IMO, the lion's share of the trap-unsafe optimizations
<u></u><u></u></p>
<p class="MsoNormal">> are before the backend. <u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The x86 backend will be responsible for the paired SSE2 instructions, won’t it? This code uses quite a lot of divides and square roots, and paired instructions without care for the other half of the pair are deadly there.</p></div></div></blockquote><div><br></div><div>The scalar constrained intrinsics would prevent vectorization, so you hopefully wouldn't see a vector sqrt/etc instruction with scalar input(s). I don't think the X86 backend itself would select a vector instruction for a scalar operation (I could be wrong).</div><div><br></div><div>If your user/frontend is issuing a vector instruction, the user/frontend would be responsible for inserting safe values as needed (or masking on targets that support it).</div><div> </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-GB"><div class="gmail-m_-8400753106683368322WordSection1">
<p class="MsoNormal">> You might get lucky trying the constrained intrinsics now (maybe). <u></u><u></u></p>
<p class="MsoNormal">> That said, performance at this point will be horrible. Perhaps worse than -O0.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Ouch.</p></div></div></blockquote><div> </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-GB"><div class="gmail-m_-8400753106683368322WordSection1">
<p class="MsoNormal">> I also require something like this for my work. The constrained intrinsics implementation
<u></u><u></u></p>
<p class="MsoNormal">> is a step in the right direction, but there's a long long way to go. You may be able to use
<u></u><u></u></p>
<p class="MsoNormal">> it to flush out Invalid/Overflow/Zero issues in the source, but would not be able to run
<u></u><u></u></p>
<p class="MsoNormal">> production quality code with traps enabled anytime soon.<u></u><u></u></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>The source is under continuous development, and we have testing with traps active on MSVC, GCC, Solaris and AIX. They can all manage this with production-quality code. So we’d be looking for problems
 created by Clang. Sadly, having floating-point traps active causes actual Clang quality problems to be hidden in the haystack of floating-point errors.</span></p></div></div></blockquote><div><br></div><div>Yes, I know. Only a small number of people are currently working on this. New contributors are welcome...<br></div></div></div></div></div>