<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 6:31 AM Dallman, John <<a href="mailto:john.dallman@siemens.com">john.dallman@siemens.com</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-GB">
<div class="gmail-m_6820821861321570946WordSection1">
<p class="MsoNormal">Vlad wrote: <u></u><u></u></p>
<p class="MsoNormal">> Unfortunately the LLVM x86 backend has at least one bug that causes FPU exceptions on valid FP operations that I know
<u></u><u></u></p>
<p class="MsoNormal">> of: <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=I2CETanc82AaRe9WkqsPsFA3dOIUifqB-6ohqLLl3SQ&s=zB8XJnn86HvBkitTORXzr5lEu3LIjrHczjFDUoGsxXA&e=" target="_blank">
https://bugs.llvm.org/show_bug.cgi?id=30885</a>. You can work around that bug by using -march=haswell, if you continue
<u></u><u></u></p>
<p class="MsoNormal">> to hit other exceptions you can file LLVM bugs against them, though I'm not sure if there is anyone actively interested in
<u></u><u></u></p>
<p class="MsoNormal">> fixing them.<u></u><u></u></p>
<p class="MsoNormal"><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"><u></u> <u></u></p>
<p class="MsoNormal">Cameron wrote: <u></u><u></u></p>
<p class="MsoNormal">> This is something we're currently working on. See:<u></u><u></u></p>
<p class="MsoNormal">> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_docs_LangRef.html-23constrained-2Dfloating-2Dpoint-2Dintrinsics&d=DwMGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=I2CETanc82AaRe9WkqsPsFA3dOIUifqB-6ohqLLl3SQ&s=UimUOotmvCJf2kFqGqbInmkQx02uML0DQ5XXW_wn_Ik&e=" target="_blank">
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics</a><u></u><u></u></p>
<p class="MsoNormal">> There's still a lot to be done though. Short of this work, I don't think you'll find guarantees of trap-safety in LLVM.<u></u><u></u></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>That seems to be saying that trap-safety will be available on those intrinsics when they’re complete.</span></p></div></div></blockquote><div><br></div><div>That's correct.</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_6820821861321570946WordSection1">
<p class="MsoNormal"><span>How about expressions written with variables holding doubles and the ordinary C arithmetic operators? My chances of getting millions of line of code that use those re-written with intrinsics are
 zero; without that, I’ll be forced to turn off floating-point traps if the -march=haswell tweak does not help.</span></p></div></div></blockquote><div><br></div><div>Those would also be represented as constrained intrinsics. E.g. <span style="color:rgb(0,0,0);font-family:Consolas,"Deja Vu Sans Mono","Bitstream Vera Sans Mono",monospace;font-size:13.300000190734863px">llvm.experimental.constrained.fadd. </span>The intrinsics are used to prevent trap-unsafe optimizations throughout LLVM.</div><div><br></div><div>There are some proposals to automatically convert normal IRBuilder calls into constrained intrinsics. E.g. D53157. </div></div></div></div>