CartesianIndex and @turbo loop

LV has been awesome for effortlessly speeding up code! Thanks!
I've recently run into some errors I don't know enough about to fix, reproduced with errors below with version v0.12.96. They're modifications of the image filtering example code. Currently the errors seem a bit too specific to me to address, and was hoping for help, or to report a bug if there's one.

In short my project involves kernels but over sparse, specific points rather than every index of a matrix so only convolving the kernel at specific `CartesianIndex`'s seems elegant. The `outerr` issue seems to take offence with making the CartesianIndex itself, while the `inerr` issue is beyond me but may be related; maybe `@turbo` doesn't like the CartesianIndex being dynamically created? The nominal image filtering example works without problems. In a previous version of LV, I had a block of code similar to the `inerr` function below working.

```julia
using LoopVectorization, OffsetArrays

x = rand(10,10)
kern = Images.Kernel.gaussian((1, 1), (3, 3))

function outerr(x, kern)
r = size(x,1)
s = zero(eltype(x))
@turbo for i=2:r-1
idx = CartesianIndex(i,i)
for K in CartesianIndices(kern)
s += x[idx+K] + kern[K]
end
end
s
end

function inerr(x, kern)
r = size(x,1)
s = zero(eltype(x))
for i=2:r-1
idx = CartesianIndex(i,i)
@turbo for K in CartesianIndices(kern)
s += x[idx+K] + kern[K]
end
end
s
end

julia> outerr(x, kern)
ERROR: ArgumentError: type does not have a definite number of fields
Stacktrace:
[1] fieldcount(t::Any)
@ Base ./reflection.jl:764
[2] _append_fields!(t::Expr, body::Expr, sym::Symbol, #unused#::Type{TypeVar})
@ LoopVectorization ~/.julia/packages/LoopVectorization/umAIq/src/condense_loopset.jl:12
[3] _append_fields!(t::Expr, body::Expr, sym::Symbol, #unused#::Type{UnionAll}) (repeats 3 times)
@ LoopVectorization ~/.julia/packages/LoopVectorization/umAIq/src/condense_loopset.jl:19
[4] #s166#66
@ ~/.julia/packages/LoopVectorization/umAIq/src/condense_loopset.jl:34 [inlined]
[5] var"#s166#66"(T::Any, ::Any, r::Any)
@ LoopVectorization ./none:0
[6] (::Core.GeneratedFunctionStub)(::Any, ::Vararg{Any})
@ Core ./boot.jl:580
[7] outerr(x::Matrix{Float64}, kern::OffsetMatrix{Float64, Matrix{Float64}})
@ Main /tmp/lv.jl:11
[8] top-level scope
@ REPL[4]:1

julia> inerr(x, kern)
ERROR: MethodError: no method matching _gesp(::LayoutPointers.StridedPointer{Float64, 2, 1, 0, (1, 2), Tuple{Static.StaticInt{8}, Int64}, Tuple{Static.StaticInt{1}, Static.StaticInt{1}}}, ::Static.StaticInt{1}, ::CartesianIndex{2}, ::Static.StaticInt{1})
Closest candidates are:
_gesp(::LayoutPointers.FastRange, ::Static.StaticInt{1}, ::Any, ::Static.StaticInt{1}) at ~/.julia/packages/LoopVectorization/umAIq/src/vectorizationbase_compat/subsetview.jl:38
_gesp(::LayoutPointers.AbstractStridedPointer{T, N, C, B, R, X, O} where {C, B, R, X<:Tuple{Vararg{Integer, N}}, O<:Tuple{Vararg{Integer, N}}}, ::Static.StaticInt{I}, ::Integer, ::Static.StaticInt{D}) where {I, N, T, D} at ~/.julia/packages/LoopVectorization/umAIq/src/vectorizationbase_compat/subsetview.jl:39
Stacktrace:
[1] inerr(x::Matrix{Float64}, kern::OffsetMatrix{Float64, Matrix{Float64}})
@ Main /tmp/lv.jl:25
[2] top-level scope
@ REPL[5]:
```

Reproduce outerr and inerr from the issue, then inspect LoopVectorization's condense_loopset.jl and vectorizationbase_compat/subsetview.jl at the stack-trace locations. Compare how dynamically created CartesianIndex values are handled in each loop. Done means establishing whether these errors are a bug or an unsupported case and documenting or addressing that result.

Vom Indexierungsmodell aus dem Issue-Text verfasst.