[llvm-dev] Why is llvm.maxnum.f32 coming through unreduced?

[Sanjay Patel via llvm-dev]

Yep - I filed the bug, but I didn't get back around to creating a patch.
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?
For Apple folks, I filed rdar://22308033 for the libm implementation.

On Sun, Nov 15, 2015 at 12:29 PM, Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 15 November 2015 at 09:01, Rodney M. Bates via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > The latter is reduced to machine code by llc, the former is not, instead
> > coming through as an external function call, which then fails to link.
>
> Is this for x86? I don't think that has a single instruction to
> implement floating-point maximum so I'd expect LLVM to produce a call
> to fmax. Sanjay seems to have proposed an efficient inlined version
> (https://llvm.org/bugs/show_bug.cgi?id=24475), but given that the
> bug's still open it probably hasn't actually been implemented.
>
> To get the libcall working (depending on the platform), you might need
> to link against libm.
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151115/44b94bac/attachment.html>