This commit moves the logic from `std.build.InstallRawStep` into `zig
objcopy`. The options here are limited, but we can add features as
needed.
closes#9261
New issues can be opened for specific objcopy flag support.
Originally I just wanted to move these down because they seemed to be in some random position of the file,
but these constants look very old with their CASING and pretty unnecessary anyway so I just inlined them.
This helps prevent errors related to undefined pointers being passed
through to some OS apis when slices have 0 length.
Tests have also been added to catch these cases.
The PCG32 fill function seems to have been copy-pasted from code using u64, so requesting `n` bytes where `(n & 7) > 4` bytes would cause the last few bytes to be all 0.
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 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.
We were missing some math functions. After this enhancement I verified
that I was able to cross-compile ninja.exe for aarch64-windows and
produce a viable binary.
On x86 interestingly I can see a reduction in codesize by 1 instruction with this.
While not necessarily faster, it might still reduce codesize a bit and this ordering is also more logical
because it follows ASCII table order. Rust's std uses this ordering too.
See https://zig.godbolt.org/z/PqodY8YqY for the difference.
This makes it so that we no longer use a LUT (Look-Up Table):
* The code is much simpler and easier to understand now.
* Using a LUT means we rely on a warm cache.
Relying on the cache like this results in inconsistent performance and in many cases codegen will be worse.
Also as @topolarity once pointed out, in some cases while it seems like the code may branch, it actually doesn't:
https://github.com/ziglang/zig/pull/11629#issuecomment-1213641429
* Other languages' standard libraries don't do this either.
JFF I wanted to see what other languages codegen compared to us now:
https://rust.godbolt.org/z/Te4ax9Edf, https://zig.godbolt.org/z/nTbYedWKv
So we are pretty much on par or better than other languages now.
