| Age | Commit message (Collapse) | Author |
|---|
|
Closes #14123
|
|
Closes #14063
|
|
When using llvm opaque pointers, typed pointers and pointer bitcasts are
no longer needed. This also avoids needing packed struct layouts that
are nested inside pointers, letting us avoid computing struct layouts
in Sema that could cause unnecessary dependency loops.
|
|
Closes #12973
|
|
llvm: handle vectors in packed structs
|
|
Closes #13201
|
|
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.
|
|
Fixes the following assertion:
```
zig: llvm/lib/IR/Type.cpp:729: static llvm::PointerType* llvm::PointerType::get(llvm::Type*, unsigned int): Assertion `isValidElementType(EltTy) && "Invalid type for pointer element!"' failed.
```
|
|
* 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.
|
|
|
|
Fixes #13937
|
|
|
|
Closes #12812
Closes #13925
|
|
Closes #9484
|
|
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.
|
|
Closes #12498
|
|
`@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}
```
|
|
closes #13535
|
|
closes #13546
|
|
Closes #13664
|
|
* ensure parameter debug info is in the subroutine di scope
* slit sub file path into basename and dirname
Closes #12257
Closes #12665
|
|
Implement tuple type declarations
|
|
|
|
|
|
std: valgrind client request support for aarch64
|
|
Closes #13605
|
|
Closes #13597
|
|
This would previously cause miscompilations when the ABI type had
bigger alignment than the raw type.
|
|
follow up on #13376 - fixes a bug in the x86_64 C ABI.
Co-authored-by: Veikka Tuominen <git@vexu.eu>
|
|
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.
|
|
|
|
Closes #13557
|
|
Closes #645
|
|
Just checking that they aren't comptime isn't enough for `@Type` constructed tuples.
Closes #13531
|
|
Closes #13522
|
|
If the field comes before any non-zero-bit field then the index of
the next field should be returned.
Closes #13363
|
|
|
|
These are supported using %[ident:mod] syntax. This allows requesting,
e.g., the "w" (32-bit) vs. "x" (64-bit) views of AArch64 registers.
See https://llvm.org/docs/LangRef.html#asm-template-argument-modifiers
|
|
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>
|
|
Closes #13340
|
|
|
|
llvm: mangle extern function names for Wasm target
|
|
Resolves #13232.
|
|
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.
|
|
Optimize size of optional slices (+ some fixes)
|
|
stage 2: Update `CType` size/alignment
|
