# @Vector abuse? **URL:** \ **Category:** Help\ **Tags:** language\ **Created:** [October 5, 2026, 3:39pm UTC](https://ziggit.dev/t/vector-abuse/17854 "2026-10-05T15:39:33Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![codegasm](https://ziggit.dev/user_avatar/ziggit.dev/codegasm/32/3035_2.png) [@codegasm](https://ziggit.dev/u/codegasm)\ **Post date:** [October 5, 2026, 3:39pm UTC](https://ziggit.dev/t/vector-abuse/17854/1 "2026-10-05T15:39:33Z")
I’m running up against two changes in Zig 0.17.0 that I didn’t see in the release notes: - `@Vector` types are no longer allowed in extern structs/unions or as parameters to functions that have `callconv(.winapi)`, due to not having a defined memory layout. - Pointers to `@Vector` fields are now aligned in such a way that you can’t pass them to a function that accepts a `*f32` pointer. These are both very hard for me to change in my project so now I’m looking for excuses to refactor my vector math to use arrays of floats rather than `@Vector` types. So I’m curious if I am abusing `@Vectors` in my current implementation of [vector math](https://github.com/zoeesilcock/handmade-zig/blob/master/src/math.zig). There’s no need to read the whole file, the first `Vector2Type` function is enough to understand what I am doing. I originally did this thinking that there would be a performance advantage to using `@Vector` when doing vector calculations since all elements of the vector can be calculated at the same time, but I’m not convinced that there would be a big difference anymore. If I end up refactoring I can obviously compare the performance, but since that’s a somewhat time consuming task I wanted to get some more opinions on this before I go down that route. ---
**Author:** ![LucasSantos91](https://ziggit.dev/user_avatar/ziggit.dev/lucassantos91/32/440_2.png) [@LucasSantos91](https://ziggit.dev/u/LucasSantos91)\ **Post date:** [October 5, 2026, 3:50pm UTC](https://ziggit.dev/t/vector-abuse/17854/2 "2026-10-05T15:50:24Z")
There’s a reasonable chance your previous code with `@Vector` was already suboptimal compared to an array. When you use `@Vector`, the compiler does not do any optimizations. It fully trusts you to write optimal code. The problem is that a lot of naive implementations of vector operations are suboptimal compared to what the compiler can do. When you write a loop over an array, the compiler detects the naive implementation and improves it. When you use `@Vector`, that doesn’t happen. ---
**Author:** ![Plebosaur](https://ziggit.dev/user_avatar/ziggit.dev/plebosaur/32/6857_2.png) [@Plebosaur](https://ziggit.dev/u/Plebosaur)\ **Post date:** [October 5, 2026, 4:04pm UTC](https://ziggit.dev/t/vector-abuse/17854/3 "2026-10-05T16:04:17Z")
I had a similiar issue, but after learning about vector - array coercion I think it makes more sense the way they have it than what I did originally, here’s a migration guide, just store [N]T instead of @Vector(N, T) and use coercion when you want to do anything with SIMD. ```zig // Before fn foo(vec: [*]@Vector(8, u32)) void { const v: @Vector(8, u32) = vec[42]; doSomething(v); } // After fn foo(vec: [*][8]u32) void { const v: @Vector(8, u32) = vec[42]; doSomething(v); } ``` I checked the assembly in my project, the only difference is that LLVM will use vmovdqu instead of vmovdqa, which is basically the same command but with different layout assumptions. AFAIK that’s the same performance. If you want to force the vmovdqa then you can just use `[*]align(vectorAlignment)[8]u32` [Compiler explorer example](https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:zig,selection:(endColumn:2,endLineNumber:10,positionColumn:2,positionLineNumber:10,selectionStartColumn:2,selectionStartLineNumber:10,startColumn:2,startLineNumber:10),source:'//+Type+your+code+here,+or+load+an+example.%0Aexport+fn+foo(vecs:+%5B*%5D@Vector(8,+u32))+void+%7B%0A++++const+v:+@Vector(8,+u32)+%3D+vecs%5B42%5D%3B%0A++++vecs%5B42%5D+%3D+v+*+@as(@Vector(8,+u32),+@splat(2))%3B%0A%7D%0A%0Aexport+fn+foo2(vecs:+%5B*%5D%5B8%5Du32)+void+%7B%0A++++const+v:+@Vector(8,+u32)+%3D+vecs%5B42%5D%3B%0A++++vecs%5B42%5D+%3D+v+*+@as(@Vector(8,+u32),+@splat(2))%3B%0A%7D%0A%0Aconst+vecalign+%3D+@alignOf(@Vector(8,+u32))%3B%0A%0Aexport+fn+foo3(vecs:+%5B*%5Dalign+(vecalign)+%5B8%5Du32+)+void+%7B%0A++++const+v:+@Vector(8,+u32)+%3D+vecs%5B42%5D%3B%0A++++vecs%5B42%5D+%3D+v+*+@as(@Vector(8,+u32),+@splat(2))%3B%0A%7D'),l:'5',n:'0',o:'Zig+source+%231',t:'0')),k:51.626124324740985,l:'4',m:100,n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:z0160,filters:(b:'1',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'0',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:zig,libs:!(),options:'-O+ReleaseFast+-fno-strip',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+zig+0.16.0+(Editor+%231)',t:'0')),header:(),k:48.373875675259015,l:'4',m:100,n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4) Edit: TLDR - store your data in arrays instead of vectors and pretend they are vectors using coercion. ---
**Author:** ![rpkak](https://ziggit.dev/letter_avatar_proxy/v4/letter/r/a4c791/32.png) [@rpkak](https://ziggit.dev/u/rpkak)\ **Post date:** [October 5, 2026, 4:43pm UTC](https://ziggit.dev/t/vector-abuse/17854/4 "2026-10-05T16:43:26Z")
> [@LucasSantos91](#): > > When you use `@Vector`, the compiler does not do any optimizations. This is wrong. Most optimizations act differently on an array vs. a vector (I haven’t looked into this that deep, but I could imagine that e.g. [sroa](https://llvm.org/docs/Passes.html#sroa-scalar-replacement-of-aggregates) does not work on vectors), but some optimizations work with vectors (e.g. turning `vec * splat(2)` into `vec << splat(1)`). ---
**Author:** ![WeeBull](https://ziggit.dev/user_avatar/ziggit.dev/weebull/32/6828_2.png) [@WeeBull](https://ziggit.dev/u/WeeBull)\ **Post date:** [October 5, 2026, 4:51pm UTC](https://ziggit.dev/t/vector-abuse/17854/5 "2026-10-05T16:51:28Z")
> [@Plebosaur](#): > > …just store [N]T instead of @Vector(N, T) and use coercion when you wan I may be retreading old ground here. It does feel to me like this is a very hairy part of the language. I personally don’t think declaring something as a vector should tell the compiler which instructions it should use to process the data. It’s saying this data structure should be interpreted as a mathematical vector, just as `@Complex()` would (if we had one) say treat these values as a complex number or `@Matrix` would say treat it as a matrix. It’s then up to the compiler to decide how to do the work efficiently. SIMD or not. I think there’s a proposal to separate SIMD semantics from vector semantics, but I can’t put my finger on it now. I think it’s desperately needed though. ---
**Author:** ![rpkak](https://ziggit.dev/letter_avatar_proxy/v4/letter/r/a4c791/32.png) [@rpkak](https://ziggit.dev/u/rpkak)\ **Post date:** [October 5, 2026, 5:28pm UTC](https://ziggit.dev/t/vector-abuse/17854/6 "2026-10-05T17:28:30Z")
There are many areas for which zig is used, that us the word vector for something (simd vectors, vectors in the mathematical sence, people coming from c++ might think vectors are arraylists). Currently in zig a `@Vector` is lowered by the llvm backend to the [llvm vector type](https://llvm.org/docs/LangRef.html#t-vector) which is very much simd related. AFAIK other backends either scalarize `@Vector`s or also use them for simd (spirv might be an exception, but I’m not sure). ---
**Author:** ![rpkak](https://ziggit.dev/letter_avatar_proxy/v4/letter/r/a4c791/32.png) [@rpkak](https://ziggit.dev/u/rpkak)\ **Post date:** [October 5, 2026, 5:43pm UTC](https://ziggit.dev/t/vector-abuse/17854/7 "2026-10-05T17:43:12Z")
One problem with the current state is, that authors of e.g. linear algebra libs assume `@Vector` is the correct type to use, which is sometimes true, but also often wrong.