The test for checking FMA_NATIVE is faulty.

[KristofferC]

We currently check for support for FMA (fused multiply add) by doing

const FMA_NATIVE = muladd(nextfloat(1.0),nextfloat(1.0),-nextfloat(1.0,2)) != 0

From #33010 (comment) @yuyichao said:

This test is wrong. Llvm has all the freedom it want to return either values for muladd no matter if fma is available. Fwiw, arm / aarch 64 even have fast muladd instruction with intermediate rounding.

[mbauman]

More details and a breadcrumb for exposing LLVM support here: #9855.

[yuyichao]

We don't really need LLVM support since we have all the information in src/processor* now.

It's hard to expose a user-facing generic, flexible and stable API but for now exposing a temperary internal API should do no worse than now (Also note that the check cannot be fixed as is since it's at most reflecting the compiling machine status)

We could simply add a function to process_*.cpp jl_is_fma_native which will be implemented as jl_test_cpu_feature(JL_X86_fma) || jl_test_cpu_feature(JL_X86_fma4) for x86, jl_test_cpu_feature(JL_AArch32_vfp4) for arm, 1 for aarch64 and 0 for fallback. Note that this is the native feature of the running machine and not taking into account any target specification.

[yuyichao]

FWIW, given the target machine people are likely going to run julia on, I feel like setting it to true for x64 should be fine......................... Assuming the user of it doesn't directly emit fma instruction of course....

[chriselrod]

The Travis Mac doesn't have fma.

Despite compiling locally on a machine where it should be true, it's somehow set to false (although running the definition in the REPL returns true) . I guess that's because

Llvm has all the freedom it want to return either values for muladd no matter if fma is available.

[JeffreySarnoff]

What if we changed
const FMA_NATIVE = muladd(nextfloat(1.0),nextfloat(1.0),-nextfloat(1.0,2)) != 0
to
const FMA_NATIVE = fma(nextfloat(1.0),nextfloat(1.0),-nextfloat(1.0,2)) != 0
(at worst) it would be correct much more often [currently, afaik everyone gets the slower version of log(::Float64)]

[oscardssmith]

Wait, that's our check? That's straight up broken. We absolutely should fix that.

[JeffreySarnoff]

now with PR #37886

[simonbyrne]

To follow up on @yuyichao's comment, we can now do:

import Base.BinaryPlatforms.CPUID

function has_fma()
    CPUID.test_cpu_feature(CPUID.JL_X86_fma) ||
    CPUID.test_cpu_feature(CPUID.JL_X86_fma4) ||
    CPUID.test_cpu_feature(CPUID.JL_AArch32_vfp4) ||
    CPUID.normalize_arch(String(Sys.ARCH)) == "aarch64"
end

This has two problems:

1. It doesn't match the cpu target used by Julia i.e. starting julia -C "nehalem" still gives has_fma() == true on my (skylake) machine.
2. It won't be constant propagated, so would need to be used with @static, i.e.:

if @static has_fma()
   ...
end

In other words, we wouldn't be able to use this for the standard library, as it would simply be reflecting the architecture of the buildbot.

[simonbyrne]

Is there a way we can query the cpu_target from within Julia?

[oscardssmith]

Theoretically #43085 should take care of this for us.