<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Mar 8, 2019 at 8:13 AM Dallman, John <<a href="mailto:john.dallman@siemens.com" target="_blank">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="m_3012035892321402595gmail-m_-8307810653427707018WordSection1">
<p class="MsoNormal">> > <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D30885&d=DwMGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=A-aoOWJQLWvbXtsXPgUQvm4HEszmHcurAWgL55WfknY&s=Ych5Hh3tYQL0Cov2Rz1mJiggcm4EvJaxSd9iVNRNgh4&e=" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=30885</a>. You can work around that bug by using -march=haswell<u></u><u></u></p>
<p class="MsoNormal">> I’ll give it a try, although I don’t hold out much hope. <u></u>
<u></u></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>That was not my problem, which is not a surprise. That issue is about converting doubles to various long integer types, which the code I work on basically doesn’t do.
<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>> How about expressions written with variables holding doubles and the ordinary C arithmetic operators?
<u></u><u></u></span></p>
<p class="MsoNormal"><span>> My chances of getting millions of line of code that use those re-written with intrinsics are zero;
<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>There’s a maybe here, in that we could plausibly get our domain-specific programming language to generate intrinsics from expressions, but since the intrinsics work isn’t finished yet, that isn’t
 a solution for this month.</span></p></div></div></blockquote><div><br></div><div>The constrained intrinsics should be fairly trap-safe from IR through the SelectionDAG. The X86 backend has not been made trap-safe yet. IMO, the lion's share of the trap-unsafe optimizations are before the backend. You might get lucky trying the constrained intrinsics now (maybe). </div><div><br></div><div>That said, performance at this point will be horrible. Perhaps worse than -O0.</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="m_3012035892321402595gmail-m_-8307810653427707018WordSection1">
<p class="MsoNormal"><span>> without that, I’ll be forced to turn off floating-point traps …<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>If I have to turn off floating-point traps, that will cause some quality disadvantage for x86 platforms compiled with Clang vs. ones that use GCC or MSVC. ARM platforms already have that disadvantage,
 because most ARM processor manufacturers leave out floating-point traps. The mathematical modeller I work on is used to create, edit or store about 45% of the world’s 3D CAD data, so this is not a trivial problem.
<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>To be clear, what I’d like is the "fpexcept.maytrap" behaviour on all floating-point arithmetic.</span> An aspect of this that is sometimes neglected with SSE2 is the need for the compiler to only use paired
 SSE2 operations that can trap if <i>both</i> registers in the SSE2 pair contain values that were either produced during the evaluation, or set up as safe values by the compiler. When you only need one square root, traps are active, and there’s garbage in the
 other SSE2 register, the garbage is negative reasonably often.</p></div></div></blockquote><div><br></div><div>Understood. I also require something like this for my work. The constrained intrinsics implementation is a step in the right direction, but there's a long long way to go. You may be able to use it to flush out Invalid/Overflow/Zero issues in the source, but would not be able to run production quality code with traps enabled anytime soon.</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>

</blockquote></div></div></div></div>