Normally when we want a pointer to the end of a struct we just add 1 to
the struct pointer. However, when it is a zero-bit struct, the pointer
type being used during lowering is often a dummy pointer type that
actually points to a non-zero-bit type, so we actually want to add 0
instead, since a zero-bit struct begins and ends at the same address.
* Initialize `big_align` with 1 as 0 is not a valid alignment.
* Add an assert to `alignForwardGeneric` to catch this issue earlier.
* Refactor valid alignment checks to call a more descriptive function.
* Handle a `null` return from `llvmFieldIndex`.
* Add a behavior test to test this code path.
* Reword this test name, which incorrectly described how pointers to
zero-bit fields behave, and instead describe the actual test.
This will make stack traces and debugging experience more consistent
in the sense that the presence of source lines in stack traces will
not be dependent on the current working directory of the running process.
There are still a few occurrences of "stage1" in the standard library
and self-hosted compiler source, however, these instances need a bit
more careful inspection to ensure no breakage.
In both backends they did not observe the Liveness information for try
instructions. Now they do. For the C backend this is necessary for
correctness; for the LLVM backend, it improves code generation.
`@llvm.dbg.value` is absolutely useless, adding a temporary alloca
to store the constant in will make it actually show up in debuggers.
The effect on performance should be minimal since there is only one
store and it the change is not applied to ReleaseSafe builds.
```zig
fn foo(a: u32, b: []const u8, c: bool, d: enum { yes, no }) void {
_ = a; _ = b; _ = c; _ = d;
}
```
before:
```
Breakpoint 1, a.foo (a=<optimized out>, b=..., c=<optimized out>, d=<optimized out>) at a.zig:18
18 _ = d;
```
after:
```
Breakpoint 1, a.foo (a=1, b=..., c=false, d=yes) at a.zig:15
15 _ = a; _ = b; _ = c; _ = d;
(gdb) p b
$1 = {ptr = 0x20854f <a.main.anon_3888> "bar", len = 3}
```
This also modifies the inline assembly to be more optimizable - instead of
doing explicit movs, we instead communicate to LLVM which registers we
would like to, somehow, have the correct values. This is how the x86_64
code already worked and thus allows the code to be unified across the
two architectures.
As a bonus, I threw in x86 support.
Adds optimizations for by-ref types to:
- .struct_field_val
- .slice_elem_val
- .ptr_elem_val
I would have expected LLVM to be able to optimize away these
temporaries since we don't leak pointers to them and they are fed
straight from def to use, but empirically it does not.
Resolves https://github.com/ziglang/zig/issues/12713
Resolves https://github.com/ziglang/zig/issues/12638
This change makes any of the `*_val` instructions check whether it's
safe to elide copies for by-ref types rather than performing this
elision blindly.
AIR instructions fixed:
- .array_elem_val
- .struct_field_val
- .unwrap_errunion_payload
- .try
- .optional_payload
These now all respect value semantics, as expected.
P.S. Thanks to Andrew for the new way to approach this. Many of the
lines here are from his recommended change, which comes with the
significant advantage that loads are now as small as the intervening
memory access allows.
Co-authored by: Andrew Kelley <andrew@ziglang.org>
When Wasm extern functions contain the same name, but have a
different module name such as `extern "a"` vs `extern "b"` LLVM will
currently resolve the two functions to the same symbol. By mangling
the name of the symbol, we ensure the functions are resolved
seperately. We mangle the name by applying <name>|<module> where
module is also known as the library name.
