feat: replace enumerate

[wangl-cc]

I'm working on the issue #393 by replacing enumerate which can be integrated in the check of loop body. However, I have some difficulties.
First, turbo for a expression instead of a symbol may cause LoadError like:

@turbo for i in 1:length(1:10)
    n = (1:10)[i+firstindex(1:10)-1]
end

may cause ERROR: LoadError: "Indexing into the following expression was not recognized: 1:10". This error is not related to this PR and not common, feel free to ignore it, if this is not allowed.
Second, for

@turbo for ix in enumerate(A)
    A[ix[1]] = ix[1] + ix[2]
end

where the index i and variable x are not unboxed. I tried to generate symbols firstly and regroup them as a tuple like this

for ix_ind = Base.OneTo(length(A))
    ix_var = A[ix_ind + firstindex(A) - 1]
    ix = (ix_ind, ix_var)
    A[ix[1]] = ix[1] + ix[2]
end

where the expression (ix_ind, ix_var) can't not be recognized. Maybe this form should not be allowed.

[codecov]

Codecov Report

Merging #397 (e47454f) into master (d077140) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #397      +/-   ##
==========================================
+ Coverage   87.19%   87.24%   +0.04%     
==========================================
  Files          38       38              
  Lines        9498     9533      +35     
==========================================
+ Hits         8282     8317      +35     
  Misses       1216     1216              

Impacted Files	Coverage Δ
src/constructors.jl	98.72% <100.00%> (+0.36%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d077140...e47454f. Read the comment docs.

[chriselrod]

First, turbo for a expression instead of a symbol may cause LoadError like:

It's not "not allowed" so much as "not supported yet".
I guess it's not common for a human to write code like that, with the range directly inserted and indexed into.
A human would just offset i instead of using i to index into a literal range.

where the index i and variable x are not unboxed. I tried to generate symbols firstly and regroup them as a tuple like this

Ideally, you could search for all ix[1]s and ix[2]s and replace them with ix_ind and ix_var, respectively:

for ix_ind = Base.OneTo(length(A))
    ix_var = A[ix_ind + firstindex(A) - 1]
    A[ix_ind] = ix_ind + ix_var
end

However, you could also disallow it for now, because what if someone was doing something other than indexing into ix?

[wangl-cc]

I guess it's not common for a human to write code like that, with the range directly inserted and indexed into.
A human would just offset i instead of using i to index into a literal range.

A human may not write code like this, but replacing enumerate may generated this code.
A enumerate for a literal range like this

for (i, n) in enumerate(1:2)
end

would be replaced like this:

for i = Base.OneTo(length(1:2))
  n = (1:2)[(i + firstindex(1:2)) - 1]
end

One possible solution is naming the literal range in loop like this

for i = Base.OneTo(length(1:2))
  r = 1:2
  n = r[(i + firstindex(r)) - 1]
end

but turbo on it shows r is not defined.
Another solution is naming it out of loop, but I have no idea how to do this.

Maybe create a block warp the setup_call and add naming before it at here?
https://github.com/JuliaSIMD/LoopVectorization.jl/blob/master/src/constructors.jl#L178-L179

[chriselrod]

Another solution is naming it out of loop, but I have no idea how to do this.

I would definitely name it out of the loop.

[chriselrod]

It would probably be easier to do this within the LoopSet constructor then, as it has a prepreamble field you can push into.

The prepreamble is executed regardless of whether LV activates, and the preamble only if it does.

[chriselrod]

Looks good to me, thanks!

[chriselrod]

Yes, moving check_inputs! in here is better.