When lowering the return type for Wasm if the calling convention is `C`,
it now correctly lower it according to what clang does as specified in:
https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md
This makes use of the same logic as the Wasm backend, ensuring the
generated code does not diverge in function signatures.
When passing arguments accross the C-ABI for the Wasm target,
we want slightly different behavior than x86_64.
For instance: a struct with multiple fields must always be passed
by reference, even if its ABI size fits in a single integer.
However, we do pass larger integers such as 128bit by value,
which LLVM will correctly lower to use double arguments instead.
When lowering a struct type to an LLVM struct type, keep track of
whether there are any underaligned fields. If so, then make it a packed
llvm struct. This works because we already insert manual padding bytes
regardless.
We could unconditionally use an LLVM packed struct; the reason we bother
checking for underaligned fields is that it is a conservative choice, in
case LLVM handles packed structs less optimally. A future improvement
could simplify this code by unconditionally using packed LLVM structs
and then make sure measure perf is unaffected.
closes#12190
This is a possible workaround for
https://github.com/llvm/llvm-project/issues/56585
On my computer it makes stage3-release go from false positive
compilation errors on the behavior tests to "segmentation fault".
Is this forwards progress or backwards progress? I have no idea.
See #11450
This is a workaround for https://github.com/llvm/llvm-project/issues/56585
which causes writes to i1 in memory to be optimized to an incorrect value.
Unfortunately, this does not save users from running into this bug with u1
in their own types.
However, this does seem to be enough to get the behavior tests working.
This resolves#11450 on my machine.
Previously, the Zig ABI size and LLVM ABI size of these types disagreed
sometimes. This code also corrects the logging messages to not trigger
LLVM assertions.
This reverts commit 2eaef84ebe968224b0cf25206abf12ea1c5e0f5a.
Here is a motivating example:
```zig
const E = union(enum) {
A: [9]u8,
B: u64,
};
```
```llvm
%test2.E = type { { i64, [1 x i8] }, i1, [6 x i8] }
```
```
error(codegen): when lowering test2.E, Zig ABI size = 16 but LLVM ABI size = 24
```
For calling convention ABI purposes, integer attributes and return
values need to have an LLVM attribute signext or zeroext added
sometimes. This commit implements that logic.
It also implements a proof-of-concept of moving the F16T type from
being a compiler_rt hack to being how the compiler lowers f16 in
functions that need to match certain calling conventions.
Closes#12054
For some targets, Clang unconditionally adds some clobbers to all inline assembly.
While this is probably not strictly necessary, if we don't follow Clang's lead
here then we may risk tripping LLVM bugs since anything not used by Clang tends
to be buggy and regress often.
LLVM does not properly handle debug info for f16 on the aarch64-windows
target, causing "fatal error: unknown codeview register H1". The
previous workaround checked only for f16 but was still vulnerable if a
type was a byval struct or tuple which had an f16 field in it.
Now I have filed an upstream issue (see
https://github.com/llvm/llvm-project/issues/56484) and broadened the
workaround to always skip debug values for this target.
Our lowerings for various LLVM types assume that we can anticipate the
alignment/layout that LLVM will generate. Among other things, this
requires that we keep the alignment of our lowered LLVM types
synchronized with their expected alignment in Zig.
- Arrays were using packed struct types, which is seems to be
incorrect since array elements are supposed to be self-aligned.
- Unions were using packed struct types for their payload, which causes
layout divergence between what stage2 expects and what LLVM generates
Consider this lowered union type:
```llvm
%Value = type { <{ i64, [8 x i8] }>, i1, [7 x i8] } ; 24 bytes, align(1)
%ErrorUnion = type { %Value, i16 } ; 26 bytes, align(2)
```
Zig expects Value to be align(8) and, by extension, for ErrorUnion to be
size 32.
The previous code here was potentially more optimal for some cases,
however, I never tested the perf, so it might not actually matter. This
code handles more cases. We can go back and re-evaluate that other
implementation if it seems worthwhile in the future.
LLVM 14 makes it so that a RHS of saturating shift left produces a
poison value if the value is greater than the number of bits of the LHS.
Zig now emits code that will check if this is the case and select a
saturated LHS value in such case, matching Zig semantics.
The constant value lowering for unions was missing a check for whether
the payload was itself an unnamed struct. Lowerings of other types
already handle this case.
closes#11971
Rather than lowering float negation as `0.0 - x`.
* Add AIR instruction for float negation.
* Add compiler-rt functions for f128, f80 negation
closes#11853
The LLVM backend was calculating the amount of padding solely based
on the payload size. However, in the case where there is no union
tag, this fails to take into account alignment.
Closes#11857
llvm: dump failed module when -femit-llvm-ir set
print_air:
* print fully qualified name
* use Type.fmt and Value.fmtValue, fmtDebug is useless
TypedValue
* handle anon structs and tuples
* fix bugs
