<div dir="ltr"><div><div>Yep - I filed the bug, but I didn't get back around to creating a patch.<br></div>As noted in the bug report: in the case where both inputs are NaN, we'd always return the 2nd NaN value. That wouldn't match the existing OSX x86 libm implementation that I checked, but that's ok?<br></div>For Apple folks, I filed rdar://22308033 for the libm implementation. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 15, 2015 at 12:29 PM, Tim Northover via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15 November 2015 at 09:01, Rodney M. Bates via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> The latter is reduced to machine code by llc, the former is not, instead<br>
> coming through as an external function call, which then fails to link.<br>
<br>
</span>Is this for x86? I don't think that has a single instruction to<br>
implement floating-point maximum so I'd expect LLVM to produce a call<br>
to fmax. Sanjay seems to have proposed an efficient inlined version<br>
(<a href="https://llvm.org/bugs/show_bug.cgi?id=24475" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=24475</a>), but given that the<br>
bug's still open it probably hasn't actually been implemented.<br>
<br>
To get the libcall working (depending on the platform), you might need<br>
to link against libm.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>