Same function, same arguments, different generated code

[KristofferC]

Consider the following small fixedsize matrix implementation together with a reduce function and two implementations of sum:

struct FixedMatrix{R,C,T,RC} <: AbstractMatrix{T}
    data::NTuple{RC, T}
end

Base.size(::FixedMatrix{R,C}) where {R, C}  = (R,C)
Base.length(::FixedMatrix{R,C,T,RC}) where {R,C,T,RC} = RC
Base.IndexStyle(::Type{<: FixedMatrix}) = IndexLinear()
Base.getindex(fm::FixedMatrix, i::Int) = fm.data[i]

@inline function myreduce(op, v0, a::FixedMatrix)
    if length(a) == 0
        return v0
    else
        s = v0
        @inbounds @simd for j = 1:length(a)
            s = op(s, a[j])
        end
        return s
    end
end

sum2(a::FixedMatrix) = myreduce(+, zero(eltype(a)), a)
sum3(a::FixedMatrix) = myreduce(+, 0.0, a)

Now, sum2 and sum3 will (should?) clearly call the same method with the same arguments when the matrix is of type Float64 (which I confirmed by putting a @which in there).

However:

julia> using BenchmarkTools

julia> m = FixedMatrix{8, 8, Float64, 64}((rand(64)...,))

julia> @btime sum2($m)
  67.113 ns (0 allocations: 0 bytes)
36.441929014270464

julia> @btime sum3($m)
  8.379 ns (0 allocations: 0 bytes)
36.441929014270464

In fact, the generated code is vastly different (one uses SIMD, the other one does not).

julia> @code_llvm sum2(m)

julia> @code_llvm sum3(m)

How can so different code be generated when the exact same function is called with the same arguments?

[KristofferC]

Also note that the built in sum time is slower than the one I wrote up there (although probably more robust against accumulating floating point errors):

julia> @btime sum($m)
  17.394 ns (0 allocations: 0 bytes)
36.441929014270464

[yuyichao]

What's m?

[KristofferC]

Sorry! m = FixedMatrix{8, 8, Float64, 64}((rand(64)...))

[fredrikekre]

julia> @btime sum2($m);
  9.603 ns (0 allocations: 0 bytes)

julia> @btime sum3($m);
  9.341 ns (0 allocations: 0 bytes)

EDIT: Above timings were for 5x5 matrix. For 8x8:

julia> @btime sum2($m);
  111.510 ns (0 allocations: 0 bytes)

julia> @btime sum3($m);
  9.231 ns (0 allocations: 0 bytes)

[KristofferC]

What version? Is the generated code the same for you?

[KristofferC]

My master was 11 days old... maybe it has been fixed already. Will look.

[fredrikekre]

I got the same generated code but for a 5x5 case. See my edit in the comment above.

[KristofferC]

Yes for 5x5 I think everything gets unrolled.

[KristofferC]

Same result on 0.5.

[JeffBezanson]

The only difference in IR seems to be a constant 0.0 vs. sitofp(0). Maybe the sitofp is enough to throw off the optimizer? I guess we should add some early constant folding to sitofp.

[Keno]

That would be either a serious bug in LLVM or a pass order problem. Either way we should find out.

[KristofferC]

Any ideas here? AFAIU this inihibits simd for the reductions in StaticArrays.

[KristofferC]

Still happens

[KristofferC]

This seems to be fixed on 0.7 🎉.

julia> @btime sum2($m)
  7.670 ns (0 allocations: 0 bytes)
35.36299421828035

julia> @btime sum3($m)
  7.603 ns (0 allocations: 0 bytes)
35.36299421828035