This implements `@splat` for vectors where the element type is
divisible by 8 and a power of two. This is fairly simple as we can
store the values directly within the virtual stack. But for
all other sizes, we must first shift and bitwise-or the values
before we can store them to fit them like a packed-struct, rather
than an array.
This implements `airSplat` for the native WebAssembly backend when
the features 'simd128' or 'relaxed-simd' are enabled. The commit
supports splat where the value lives in the linear memory segment,
as well as on the stack. This saves a lot of instruction cost.
When it detects the element type is not 8, 16, 32 or 64 bits,
the backend will instead use the same strategy as if the features
where disabled.
This implements loading and storing immediate values representing
a vector with exactly 128 bits. When the vector does not equal to
128 bits, or when the simd128 or relaxed-simd features are disabled
the value will be treated as an array instead.
This adds the opcodes for both the simd128 and relaxed-simd features.
Those instructions are required by the self-hosted WebAssembly
backend. Additionally, this also adds the new `v128` Valtype which
is required to represent a 128bit simd value. SIMD values that do
not have exactly 128 bits will be represented differently.
This fixes a class of bugs on macOS where a segfault happening in
a loaded dylib with no debug info would cause a panic in the panic
handler instead of simply noting that the dylib has no valid debug
info via `error.MissingDebugInfo`. An example could be code linking
some system dylib and causing some routine to segfault on say invalid
pointer value, which should normally cause Zig to print an incomplete
stack trace anchored at the currently loaded image and backtrace all
the way back to the Zig binary with valid debug info. Currently, in
a situation like this we would trigger a panic within a panic.
This includes the latest changes from master branch with fixes to the C
backend that affect aarch64-windows which are necessary to build from
source on this target.
This allows using `zig ar` for `CMAKE_AR`. Unfortunately, it requires a
patch to CMakeLists.txt and cannot be done merely with flags to the
cmake line.
We definitely want a shared lock on a cache hit. Without this, we get a
deadlock when Zig is asked to compile the same C source file multiple
times as part of the same compilation.
This is a partial revert of 8ccb9a6ad327a4d7fbc321b33d4aa66a27a1f5ee.
cc @kcbanner
These bugs were triggered in the C backend by aarch64-specific code in
os/windows.zig. Intentionally not updating zig1.wasm yet because of
upcoming changes and since aarch64-windows is not tested on master yet.
