Repeated `@btime` with different setup behaves bad

function sumN(N)
    s = zero(N)
    for i in 1:N
        s += i
    end
    s
end

julia> @btime sumN(N) setup=(N=1_000_000)
  2.424 ns (0 allocations: 0 bytes)
500000500000

julia> @btime sumN(N) setup=(N=1_000_000e0)
  2.424 ns (0 allocations: 0 bytes)
500000500000

julia> @btime sumN(N) setup=(N=1_000_001e0)
  1.330 ms (0 allocations: 0 bytes)
5.00001500001e11

julia> @btime sumN(N) setup=(N=1_000_001)
  1.330 ms (0 allocations: 0 bytes)
5.00001500001e11

julia> @btime sumN(M) setup=(M=1_000_001)
  1.993 ns (0 allocations: 0 bytes)
500001500001

The Float64 trial should run slowly, and return a Float64, whereas the Int trial should run in a couple of ns and return an Int. Is there some caching of the setup going on, which uses == instead of ===?

Reproduce the repeated @btime commands from the issue, including the Int and Float64 setup values and the M variable case. Trace how @btime handles repeated setup expressions and compare values using == versus ===. Done means distinct setup types are benchmarked correctly and the reported result preserves the expected numeric type.