* Fix codegen for splat - instead of giving vectors of length N
to shufflevector for both of the operands, it gives vectors of length
1. The mask vector is the only one that needs N elements.
* Separate Splat into SplatSrc and SplatGen; the `len` is not needed
once it gets to codegen since it is redundant with the result type.
* Refactor compile error for wrong vector element type so that the
compile error message is not duplicated in zig source code
* Improve implementation to correctly handle comptime values such as
undefined and lazy values.
* Improve compile error for bad vector element type to point to the
correct place.
* Delete dead code.
* Modify behavior test to use an array cast instead of vector element
indexing since I'm merging this splat commit out-of-order from
Shawn's patch set.
* update docs for `@byteSwap`.
* fix hash & eql functions for ZigLLVMFnIdBswap not updated to
include vector len. this was causing incorrect bswap function
being called in unrelated code
* fix `@byteSwap` behavior tests only testing comptime and not
runtime operations
* implement runtime `@byteSwap`
* fix incorrect logic in ir_render_vector_to_array and
ir_render_array_to_vector with regards to whether or not to bitcast
* `@byteSwap` accepts an array operand which it will cast to vector
* simplify `@byteSwap` semantic analysis code and various fixes
* update documentation
- move `@shuffle` to be sorted alphabetically
- remove mention of LLVM
- minor clarifications & rewording
* introduce ir_resolve_vector_elem_type to avoid duplicate compile
error message and duplicate vector element checking logic
* rework ir_analyze_shuffle_vector to solve various issues
* improve `@shuffle` to allow implicit cast of arrays
* the shuffle tests weren't being run
I change the semantics of the mask operand, to make it a little more
flexible. There is no real danger in this because it is a compile-error
if you do it the LLVM way (and there is an appropiate error to tell you
this).
v2: avoid problems with double-free
* bitcasting is still better when the size_in_bits aligns with the ABI
size of the element type. Logic is reworked to do bitcasting when
possible
* rather than using insertelement/extractelement to work with arrays,
store/load elements directly. This matches codegen for arrays
elsewhere.
* Reuse bytes of async function frames when non-async functions
make `noasync` calls. This prevents explosive stack growth.
* Zig now passes a stack size argument to the linker when linking ELF
binaries. Linux ignores this value, but it is available as a program
header called GNU_STACK. I prototyped some code that memory maps
extra space to the stack using this program header, but there was
still a problem when accessing stack memory very far down. Stack
probing is needed or not working or something. I also prototyped
using `@newStackCall` to call main and that does work around the
issue but it also brings its own issues. That code is commented out
for now in std/special/start.zig. I'm on a plane with no Internet,
but I plan to consult with the musl community for advice when I get a
chance.
* Added `noasync` to a bunch of function calls in std.debug. It's very
messy but it's a workaround that makes stack traces functional with
evented I/O enabled. Eventually these will be cleaned up as the root
bugs are found and fixed. Programs built in blocking mode are
unaffected.
* Lowered the default stack size of std.io.InStream (for the async
version) to 1 MiB instead of 4. Until we figure out how to get
choosing a stack size working (see 2nd bullet point above), 4 MiB
tends to cause segfaults due to stack size running out, or usage of
stack memory too far apart, or something like that.
* Default thread stack size is bumped from 8 MiB to 16 to match the
size we give for the main thread. It's planned to eventually remove
this hard coded value and have Zig able to determine this value
during semantic analysis, with call graph analysis and function
pointer annotations and extern function annotations.
The comment added by this commit is copied here:
For macOS stack traces, we want to avoid having to parse the compilation unit debug
info. As long as each debug info file has a path independent of the compilation unit
directory (DW_AT_comp_dir), then we never have to look at the compilation unit debug
info. If we provide an absolute path to LLVM here for the compilation unit debug info,
LLVM will emit DWARF info that depends on DW_AT_comp_dir. To avoid this, we pass "."
for the compilation unit directory. This forces each debug file to have a directory
rather than be relative to DW_AT_comp_dir. According to DWARF 5, debug files will
no longer reference DW_AT_comp_dir, for the purpose of being able to support the
common practice of stripping all but the line number sections from an executable.
closes#2700
When `@frameSize` is never called, and `@asyncCall` on a runtime-known
pointer is never used, no prefix data for async functions is needed.
Related: #3160
* `await @asyncCall` generates better code. See #3065
* `@asyncCall` works with a real `@Frame(func)` in addition to
a byte slice. Closes#3072
* `@asyncCall` allows passing `{}` (a void value) as the result
pointer, which uses the result location inside the frame.
Closes#3068
* support `await @asyncCall` on a non-async function. This is in
preparation for safe recursion (#1006).
