at-views macro to convert a whole block of code to slices=views

[stevengj]

This PR provides an @views macro that you can apply to a whole block of code (e.g. a whole function definition) to convert every array-slicing operation into a view. Scalar indexing is not affected.

This allows you to opt-in to slices=views with minimal effort, a lot easier than adding @view or calls to view everywhere. This is especially easier for updating operations like .+=, where you can't put view on the left-hand side (as discussed on discourse).

[mbauman]

replace_ref_end!?

[stevengj]

Good catch, thanks.

[mbauman]

Was this really necessary in your testing? I'd be surprised if the @propagate_inbounds definitions above have a splatting penalty since they get inlined.

[stevengj]

I tried a simple test case

f(x) = 1
f(x,y) = 2
g(x...) = f(x...)

and it wasn't getting inlined, but I guess I should try again with @propagate_inbounds?

[stevengj]

Hmm, I think I was getting deceived: @code_llvm g(3) looks more complicated than @code_llvm f(3), but foo() = g(3) + g(4) - g(6,7) + g(8) is definitely inlining g (and simplifies to ret i64 1).

Great, that will simply things. The dotview function in broadcast.jl can be similarly simplified.

[mbauman]

Yeah, @code_llvm can be deceiving with splatted @inline functions because it shows the LLVM function for them... but that's not at all what happens when they get inlined into another function. I almost always will define simple fixed-argument wrapper functions when I'm trying to test these guys.

[tkelman]

does this need an array-of-arrays special case like dotview has?

[stevengj]

No, because for scalar indexing it already gives getindex

[stevengj]

Okay to merge? @StefanKarpinski, any thoughts on this?

[stevengj]

Since it seems everyone likes this, I'll merge in a day or so if there are no further objections.

[StefanKarpinski]

Sorry, I was traveling but I do have one thought: why not just fold this into the existing @view macro? I.e. if you write @view A[1,2:end-1,:] that will work but you can also write

@view begin
     # in here all indexing expressions create views
end

Grammatically, having @view and @views reads better, but it seems somewhat unnecessary to have both of these macros when they do such similar things.

[stevengj]

Well, they aren't quite the same. @views A[B[1:10]] will use views for both the A and B slices, but @view A[B[1:10]] will only use a view for the A slice.

That being said, I suspect that @views is much more useful, so we might want to simply deprecate @view?

[mbauman]

They (also) behave differently in the scalar case. @view will always return a view (including a 0-dimensional one), whereas @views will return scalars for scalar indexing. I had the same thought initially, but I think the @views behavior is generally more useful and it'd be breaking to change @view's scalar behaviors.

[StefanKarpinski]

It seems like having both @view and @views makes a fair bit of sense. The differences should be well documented so that people know why both exist despite similarities.