<div dir="ltr">On Thu, Sep 12, 2013 at 2:03 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
Please review the attached patch which restores the libm sqrt* -> @llvm.sqrt* mapping, but only in fast-math mode (specifically, when the UnsafeFPMath or NoNaNsFPMath CodeGen options are enabled). The @llvm.sqrt* intrinsics have slightly different semantics from the libm call, specifically, they are undefined when given a non-zero negative number (the libm calls will always return NaN for any negative number).<br>

<br>
This mapping was removed in r100613, and replaced with a TODO, but at that time the fast-math flags were not yet implemented. Now that we have these, restoring this mapping is important because it will enable autovectorization of sqrt calls in loops (at least in fast-math mode).<br>
<br></blockquote><div><br></div><div>This is dangerous, if LangRef is actually correct.  People don't associate -ffast-math with "my program will crash at random". :)  Of course, LangRef is probably overstating the issue.</div>
<div><br></div><div>That said, there's actually a general issue here: if we map the LLVM intrinsics to libc functions, and the libc functions set errno, we could break code that depends on errno for non-math calls (e.g. fopen().)</div>
</div><br></div><div class="gmail_extra">-Eli</div></div>