allocations when performing no-op convert on struct instance with Union fieldtype

[jrevels]

There might be a better MWE for this, I'm not sure why it happens (codegen perf bug, I'm guessing?):

julia> using BenchmarkTools

julia> struct FooA{X}
           x::X
       end

julia> F, f = FooA{Int}, FooA{Int}(1)
(FooA{Int64}, FooA{Int64}(1))

julia> @btime convert($F, $f)
  0.035 ns (0 allocations: 0 bytes)
FooA{Int64}(1)

julia> @code_lowered convert(F, f)
CodeInfo(
123 1 ─     return %%x                                                                                            │
)

julia> @code_llvm convert(F, f)

; Function convert
; Location: essentials.jl:123
define { i64 } @julia_convert_32884(%jl_value_t addrspace(10)*, { i64 } addrspace(11)* nocapture nonnull readonly dereferenceable(8)) {
top:
  %2 = getelementptr inbounds { i64 }, { i64 } addrspace(11)* %1, i64 0, i32 0
  %.unpack = load i64, i64 addrspace(11)* %2, align 8
  %3 = insertvalue { i64 } undef, i64 %.unpack, 0
  ret { i64 } %3
}

julia> struct FooB{X}
           x::Union{X,Nothing}
       end

julia> F, f = FooB{Int}, FooB{Int}(1)
(FooB{Int64}, FooB{Int64}(1))

julia> @btime convert($F, $f)
  56.547 ns (2 allocations: 64 bytes)
FooB{Int64}(1)

julia> @code_lowered convert(F, f)
CodeInfo(
123 1 ─     return %%x                                                                                            │
)

julia> @code_llvm convert(F, f)

; Function convert
; Location: essentials.jl:123
define void @julia_convert_33024({ i64, i8 }* noalias nocapture sret, %jl_value_t addrspace(10)*, { i64, i8 } addrspace(11)* nocapture nonnull readonly dereferenceable(16)) {
top:
  %3 = bitcast { i64, i8 }* %0 to i8*
  %4 = bitcast { i64, i8 } addrspace(11)* %2 to i8 addrspace(11)*
  call void @llvm.memcpy.p0i8.p11i8.i64(i8* %3, i8 addrspace(11)* %4, i64 16, i32 8, i1 false)
  ret void
}

[KristofferC]

I think this is the reason #27685 was required.

Jameson mentions the convert there #27685 (comment)

[jrevels]

Keno/Jameson say that to investigate this we should investigate how the convert call is being inlined into the benchmark loop/kernel.

[KristofferC]

The benchmark loop calls the kernel as

301 │    %18  = π (FooB{Int64}, Core.Compiler.Const(FooB{Int64}, false))                                    │
    │    %19  = π (FooB{Int64}(1), Core.Compiler.Const(FooB{Int64}(1), false))                              │
    │           invoke Main.:(##core#368)(%18::Type, %19::FooB{Int64})    

and my guess is that it is not getting specialized on the Type argument.

I've learned that almost every time one feels the @code reflection macros lie to you, it is because of specialization heuristics.

[KristofferC]

And indeed, applying the following diff to BenchmarkTools

diff --git a/src/execution.jl b/src/execution.jl
index 970b887..9d4f705 100644
--- a/src/execution.jl
+++ b/src/execution.jl
@@ -276,7 +276,11 @@ function generate_benchmark_definition(eval_module, out_vars, setup_vars, core,
     id = Expr(:quote, gensym("benchmark"))
     corefunc = gensym("core")
     samplefunc = gensym("sample")
+    type_vars = [gensym() for i in 1:length(setup_vars)]
     signature = Expr(:call, corefunc, setup_vars...)
+    signature_def = Expr(:where, Expr(:call, corefunc,
+                                  [Expr(:(::), setup_var, type_var) for (setup_var, type_var) in zip(setup_vars, type_vars)]...)
+                    , type_vars...)
     if length(out_vars) == 0
         invocation = signature
         core_body = core
@@ -290,7 +294,7 @@ function generate_benchmark_definition(eval_module, out_vars, setup_vars, core,
         core_body = :($(core); $(returns))
     end
     return Core.eval(eval_module, quote
-        @noinline $(signature) = begin $(core_body) end
+        @noinline $(signature_def) = begin $(core_body) end
         @noinline function $(samplefunc)(__params::$BenchmarkTools.Parameters)
             $(setup)
             __evals = __params.evals

(forcing specialization on arguments) and we get

julia> struct FooB{X}
           x::Union{X,Nothing}
       end

julia> F, f = FooB{Int}, FooB{Int}(1)
(FooB{Int64}, FooB{Int64}(1))

julia> @btime convert($F, $f)
  1.794 ns (0 allocations: 0 bytes)
FooB{Int64}(1)

[KristofferC]

Closing since this is an artifact of the benchmarking system.

[jrevels]

Thanks for investigating this @KristofferC!

(leaving mostly as a note for myself when/if I revisit this): I tracked these allocations down to this MWE by reducing from more complicated test code; it's likely that the lack of specialization happening in the benchmark kernel was modeling a similar lack of specialization in the test code (that I guess is one "call level" higher than this MWE), which is why the benchmark showed results here that seemed representative.