As far as why some of these forms allow for constant propagation and some don’t, it appears as though there was a strange edge case in the compiler back in the 0.7 timeframe that prompted a simple workaround . That’s no longer necessary.
JuliaLang:master
← JuliaLang:mb/revert26418
opened 03:29PM - 05 Apr 19 UTC
This used to be necessary to avoid a strange edge case in the compiler, but it i… s no longer necessary -- and can now in fact cause other performance snags.
Using the test case from [the original discourse post that prompted #26418](https://discourse.julialang.org/t/performance-degradation-of-fill-in-latest-julia-0-7-dev/9648):
```julia
# BEFORE
julia> @btime fill(1.0,5,5);
49.335 ns (1 allocation: 288 bytes)
julia> @btime fill(0.0,5,5);
52.773 ns (1 allocation: 288 bytes)
# AFTER
julia> @btime fill(0.0,5,5);
46.724 ns (1 allocation: 288 bytes)
julia> @btime fill(1.0,5,5);
42.202 ns (1 allocation: 288 bytes)
```
Even more compelling is the case for a larger array where LLVM can exploit some sort of wider/simdier implementation for zeros when this gets inlined thanks to constant propagation:
```julia
# AFTER
julia> A = Array{Float64}(undef, 1000, 1000);
julia> @btime fill!($A,0.0);
345.103 μs (0 allocations: 0 bytes)
julia> @btime fill!($A,1.0);
458.976 μs (0 allocations: 0 bytes)
```
Ref https://discourse.julialang.org/t/performance-of-filling-an-array/22788