llvm dev - Nov 2015 - Why is llvm.maxnum.f32 coming through unreduced?

On 11/15/2015 01:29 PM, Tim Northover 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.
Yes, it's x86_64.  That makes sense, but I can't find the needed
library,
which was what I first tried.  I already have -lm in my link command, and
nm on my libm doesn't get it.

With a link name like "llvm.maxnum.f32", I would expect it to be
provided
by the llvm distribution.  But I find no occurrence in either my installed
lib directory nor my build directory, using nm and grep.  The closest I can
find is a mangled name with only "maxnum" as a substring.  In my
source
directory, it occurs only in llvm assembly code, with a "@" prefix, in
subdirectories doc and test.

Am I be missing part of llvm?  I do have compiler-rt.
>
> To get the libcall working (depending on the platform), you might need
> to link against libm.
>
> Cheers.
>
> Tim.
>
-- 
Rodney Bates
rodney.m.bates at acm.org

On 16 November 2015 at 09:45, Rodney M. Bates <rodney_bates at lcwb.coop>
wrote:
> With a link name like "llvm.maxnum.f32", I would expect it to be
provided
> by the llvm distribution.
Ah, it ought to have been converted into an "fmaxf" call. It's
possible that's a bug in LLVM 3.6 and the intrinsic wasn't supported
on x86 then, since it works for me on trunk:

$ cat simple.ll
define float @foo(float %l, float %r) {
  %res = call float @llvm.maxnum.f32(float %l, float %r)
  ret float %res
}
declare float @llvm.maxnum.f32(float, float)
$ bin/llc -mtriple=x86_64-apple-darwin simple.ll -o -
[...]
foo:                                    # @foo
    .cfi_startproc
# BB#0:
    jmp fmaxf                   # TAILCALL
    .cfi_endproc

Alternatively (if that works for you too), it might be some kind of
misconfiguration in your front-end, though that seems a bit unlikely.

Tim.

On 11/16/2015 11:54 AM, Tim Northover wrote:
> On 16 November 2015 at 09:45, Rodney M. Bates <rodney_bates at
lcwb.coop> wrote:
>> With a link name like "llvm.maxnum.f32", I would expect it to
be provided
>> by the llvm distribution.
>
> Ah, it ought to have been converted into an "fmaxf" call.
It's
> possible that's a bug in LLVM 3.6 and the intrinsic wasn't
supported
> on x86 then, since it works for me on trunk:
>
> $ cat simple.ll
> define float @foo(float %l, float %r) {
>    %res = call float @llvm.maxnum.f32(float %l, float %r)
>    ret float %res
> }
> declare float @llvm.maxnum.f32(float, float)
> $ bin/llc -mtriple=x86_64-apple-darwin simple.ll -o -
> [...]
> foo:                                    # @foo
>      .cfi_startproc
> # BB#0:
>      jmp fmaxf                   # TAILCALL
>      .cfi_endproc
>
> Alternatively (if that works for you too), it might be some kind of
> misconfiguration in your front-end, though that seems a bit unlikely.
>
Thanks, this got me going.  Actually, it was an installation error.
llc 3.6.1 handles it correctly, but an old llc 3.4.2 was getting picked
up instead, and it does not.
> Tim.
>
-- 
Rodney Bates
rodney.m.bates at acm.org