Fix _vstore_unroll! for nested W=1 (scalar lane) VecUnroll

[ChrisRackauckas]

Summary

Fixes a MethodError for _vstore_unroll! when storing a doubly-unrolled scalar (W=1) VecUnroll — the case that LoopVectorization can generate on Apple ARM (and other narrow-SIMD targets) for a @turbo loop with both a static length-1 inner dimension and double unrolling.

The value type at the failing call site is:

VecUnroll{NO_m1, 1, T, VecUnroll{NI_m1, 1, T, T}}

Note the innermost type is the scalar T, not Vec{1,T}, because the VecUnroll constructor unwraps width-1 vectors. The existing generated _vstore_unroll! methods for nested unrolls (memory.jl:2575/2620/2664/2710) all match <:VecUnroll{<:Any,W,T,Vec{W,T}} as the innermost, so this case falls through to no method.

The fix adds a method specialized on VecUnroll{NO_m1,1,T,<:VecUnroll{NI_m1,1,T,T}} with a nested Unroll{...,1,...,<:Unroll{...,1,...}} index. It forwards to the existing single-unroll _vstore_unroll! (the generic VecUnroll{Nm1,W,VUT,<:VecOrScalar} overload at memory.jl:1174) once per outer index, mirroring the "else" branch of vstore_double_unroll_quote.

Context

This is the _vstore_unroll! counterpart to the W=1 scalar _vstore! overloads that already exist at memory.jl:2106-2218 for single-level unrolls.

This fixes LoopVectorization.jl issue #543 on Apple M-series CPUs, where the W=1 nested static-dimension matmul-style loops produced a MethodError: no method matching _vstore_unroll!(...VecUnroll{N,1,Float64,VecUnroll{N,1,Float64,Float64}}...) for certain shapes (e.g. n=3, n=5 in the test in LoopVectorization.jl/test/staticsize.jl).

Part of the SciML small grant for updating LoopVectorization.jl to pass all tests on macOS ARM.

Test plan

• Local: With this branch dev'd into LoopVectorization.jl, staticsize.jl's "Issue #543: W=1 Nested VecUnroll" test set passes for all v∈1:4, n∈2:8 on Apple M-series (previously failed at n=3, n=5 with v=1).
• CI: macOS-latest (aarch64) green.
• CI: x86_64 platforms unaffected (new method is only reachable when both outer and inner unroll widths are 1, and innermost VecUnroll element type is scalar T).

🤖 Generated with Claude Code

[ChrisRackauckas]

Pushed a second commit adding a separate fix for BitVector dynamic-index load misalignment.

The vload_quote_llvmcall_core Bit path emits load <W x i1> from a byte-aligned pointer computed as ptr + (index >> 3). That only reads the correct W bits when index & 7 == 0. Tail/cleanup unroll iterations of @turbo loops that step by W*UN < 8 hit non-byte-aligned bit indices and read the wrong bits. The bug exists on every architecture but only manifests in the LV test suite on Apple ARM, because NEON's W=2 for Float64 puts the cleanup tail right where the misalignment lands; x86 AVX2/AVX-512 widths happen to dodge the failing seeds in those tests.

The fix issues a wider integer load (nextpow2(W+7) bits), shifts right by index & 7, and truncates to <W x i1> so downstream code is unchanged. Gated on isbit && dynamic_index && (ind_type === :Integer) && !grv && !mask && !reverse_load && W > 1.

Local Apple M-series results: Bernoulli_logitavx(BitVector, ::Vector{Float64}) and (BitVector, ::Vector{Int}) pass 30/30 random seeds (was ~10-20% by luck before). Full test/ifelsemasks.jl: 435/435 pass, 0 broken, 0 errors. test/copy.jl, dot.jl, gemm.jl, gemv.jl, convolutions.jl, filter.jl, map.jl, mapreduce.jl, offsetarrays.jl, reduction_untangling.jl, miscellaneous.jl, staticsize.jl: all green. Companion test changes in JuliaSIMD/LoopVectorization.jl#569.

Same caveats as before — masked / reverse-load / gather variants of the bit path may have the same alignment issue but are not covered by this patch; they aren't exercised by the failing tests. If x86 CI surfaces a regression we can gate the new branch on Sys.ARCH ∈ (:aarch64, :arm).

[ChrisRackauckas]

CI is green on every test that this PR actually changes the behavior of:

• LoopVectorization.jl/Interface/{1, lts, pre}: all pass. The original Failed to parse LLVM assembly errors on the LTS interface (Julia 1.10, non-opaque pointers) are fixed by the bitcast <W x i1>* → iN* added in commit 00bf116.
• TriangularSolve.jl/Interface/{1, lts, pre}: all pass.
• Doctests, Documentation: pass.

The remaining failures are all pre-existing infrastructure issues unrelated to this PR:

• Julia {1, lts, pre} × {macOS-x64, ubuntu-x64/x86, windows-x64}: Each fails on one Aqua Method ambiguity check (~2.3M tests pass per platform, 1 Aqua check fails). The ambiguity is between Static.jl's convert(::Type{Static.True/False/StaticInt{N}}, ::Number) methods and this package's existing convert(::Type{T}, ::LazyMulAdd) where T<:Number at src/lazymul.jl:25. It's exposed by newer Static.jl + Aqua versions auto-resolved at CI time; master CI from August 2025 didn't see it. Pre-existing latent — independent of any change in this PR.
• SLEEFPirates.jl/Interface/{1,lts,pre} and VectorizedRNG.jl/Interface/{1,lts,pre}: same story — Aqua deps_compat / piracy checks in those downstream packages, plus a numerical accuracy delta in SLEEFPirates' asinh/tan/sin tests. Pre-existing.
• evaluate: SnoopCompile.jl SCPrettyTablesExt raises FieldError: type Nothing has no field 'name' while reporting method invalidations. CI infrastructure bug.

So the functional change is doing its job and the downstream packages we actually compile + run still test green. Happy to add Static-side convert overloads to silence the Aqua ambiguity in a follow-up if useful — but it would be a separate concern from the macOS-ARM grant work this PR is tracking.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 61 lines in your changes missing coverage. Please review.
✅ Project coverage is 0.00%. Comparing base (5cd4e0b) to head (283fe18).

Files with missing lines	Patch %	Lines
src/vecunroll/memory.jl	0.00%	39 Missing ⚠️
src/llvm_intrin/memory_addr.jl	0.00%	22 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff           @@
##           master    #127   +/-   ##
======================================
  Coverage    0.00%   0.00%           
======================================
  Files          35      35           
  Lines        6134    6170   +36     
======================================
- Misses       6134    6170   +36     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[oscardssmith]

time to drop pre 1.10?

[ChrisRackauckas]

Need to bump beyond v1.10 to drop this, it's <=. So it stays for now.

[oscardssmith]

Anything specific you want me to review here?