Make StridedReinterpretArray's get/setindex pointer based.

[N5N3]

This PR make StridedReinterpretArray's get/setindex pure pointer based if its root parent is a Array.
Thus a "Dense" ReinterpretArray should behave more like a Array.
Some examples with better performance:

julia> a = randn(ComplexF64, 100, 100); b = randn(100); c = a * b;
julia> aa = reinterpret(Float64, a); cc = reinterpret(Float64, c);
julia> @btime LinearAlgebra.generic_matvecmul!($cc, 'N', $aa, $b, LinearAlgebra.MulAddMul(true,false));
  2.544 μs (0 allocations: 0 bytes)  # on master 116.900 μs (0 allocations: 0 bytes)

julia> f(x, y) = @inbounds @simd ivdep for i in eachindex(x,y) # ivdep here is useless on master
       x[i] = ntoh(y[i])
       end

julia> a = reinterpret(Float64, rand(UInt8, 16000));

julia> @btime f($a, $a)
  124.388 ns (0 allocations: 0 bytes) # on master 697.260 ns (0 allocations: 0 bytes)

Test has been extended thus all branches should be tested.

[jishnub]

@N5N3 this PR seems to provide a significant performance boost for reinterpreted arrays. If you're happy with this, would you mind recommending some reviewers so that it might move ahead?

Ref: https://discourse.julialang.org/t/reinterpretedarray-performance-even-worse-on-1-8/80102/27

[N5N3]

This PR is mainly for the performance of a reinterpreted (contigious) buffer.
It should be a common usage so I think specific optimizaiton is OK.
The main concern might be the safey. Hope @vtjnash has time to give some suggestion.

[jishnub]

Gentle bump

[ronisbr]

One possible use case that might benefit from this PR:

https://discourse.julialang.org/t/slowdown-with-reinterpret/91749

[j-fu]

In fact reinterpret helps a lot when different approaches to handle e.g. coordinate arrays for discretization grids need to be reconciled. E.g. mesh generators written in C/C++ may return a 3xn matrix of coordinates, and this could be readily reinterpreted e.g. as a Vector{Point3}, and vice versa. So I think the use case is not very exotic.

[gbaraldi]

@nanosoldier runtests()

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here.

[Moelf]

bump, this helps greatly for some of the long-standing performance issues w.r.t. StridedReinterpretArray

[vtjnash]

I removed the unsafe_convert method added here, since it does not seem correct, vis a vis 0a0bd00. Let's see how CI is doing

[N5N3]

Unfortunately, I can confirm this PR blocks Vectorization in some simple cases.

julia> typeof(aa)
Base.ReinterpretArray{Int64, 2, Float64, Matrix{Float64}, false}

julia> @btime fill!($aa, 1);
  1.590 μs (0 allocations: 0 bytes)

julia> Base.check_store(::Array) = false

julia> @btime fill!($aa, 1);
  1.010 μs (0 allocations: 0 bytes)

[vtjnash]

Ah okay. Is that because this intercepts at sort of a bad point, so rather than doing all-native load/store/bitcast for simple cases like Int64<->Float64, now those always go through our unsafe primitives, that are only supposed to be for C-compatibility, of unsafe load/store, and then lose out on the efficiency benefits of the native primitives?

[N5N3]

I thought LLVM might prefer unsafe_store!(p, v, li) rather than unsafe_store!(p + sizeof(T) * (li - 1), v).
But the "regression" is not fixed.
unsafe_store!(p, v, li) is fully intrinsiced based, and it does make LLVM IR simpler, but LLVM still refused to generate Vectorization block.

[vtjnash]

I think there is roughly 2 cases here:

• isprimitivetype for both source and dest
• only isbitstype

For isprimitivetype, it looks like we might be only using native operations currently, and those will end in LLVM as a load/store into registers. That seems the case where it looks like it should be already capable of emitting the optimal code, so this can only make it worse by using unsafe operations which requires the compiler to destroy useful information (e.g. vectorizability).

For everything else, it looks like we always use a native load from the array too, but for other cases we know that will turn into a memcpy to a stack slot, then we do a move from that stack slot to a Ref, then we do an unsafe_load of that Ref, which we know will also turn into a memcpy to yet another stack slot, and finally we return that, which should do one final copy from that stack slot to the sret. After inlining and optimizations, most of those copies should go away (those are the same copies we would expect if this wasn't a reinterpret, but merely a copy via a Ref(x)[], so this should not be too unusual of IR)

[N5N3]

Tried some bisect locally.
This PR still works fine without #51319, so this looks like a fresh "regression".

[vtjnash]

Sure, but we know doing stuff with unsafe_ operations is expected to perform badly. The advantage of this PR seems to be that since it was already using the bad unsafe_ operations in many cases, that sometimes there are ways to make those more direct (with unsafe_load) instead of waiting for LLVM to transform them to something roughly equivalent

[N5N3]

Tried to play with LLVM a bit. Looks like LV dislikes the GC preserved MemoryRef.
Fortunately, Memory stores Ptr directly and would be vectorlizable after reinterpretation. If vectorlization does matter, then user can transform a reinterpreted Array into a reinterpreted + viewed/reshaped Memory to get full speed.

[vtjnash]

We should probably now define that parent(::Array) = getfield(array.ref.mem), like all the other types. But a viewed/reshaped Memory typically is an Array. Although maybe you meant you also needed it to be a non-mutable object?

[N5N3]

Although maybe you meant you also needed it to be a non-mutable object?

Yes, I mean Base.SubArray and Base.ReshapedArray