That could be interesting to experiment with. Though I’d probably just switch the data representation based on julia version rather than ceasing support for earlier versions. As long as that’s not disruptive in some other way.
Exactly. @maleadt could you shed some light on this?
Generally I feel like StaticArrays must rely on the optimizer in the long term because it knows target-specific details which we will never know in the library. So it’s a game of getting enough information to the optimization passes that they can do the best thing. (That also needs to be balanced with allowing good information in type inference. Unrolling just so happens to make this much easier, but we may need to stop relying on that crutch).
Ideally LoopVectorization would be an optimization pass which StaticArrays could send metadata to, and it figures out what to do based on the compilation target. (Basically like @simd I guess, though it would be great if it didn’t need to be built in to start with.)