minFunctionAlignment() is something we can know ahead of time for any given
target because it's a matter of ABI. However, defaultFunctionAlignment() is a
matter of optimization and every backend can do it differently depending on any
number of factors. For example, LLVM will base the choice on the CPU model in
its aarch64 backend. So just don't use this value in the frontend.
defaultFunctionAlignment() can be made more sophisticated over time based on the
CPU model and/or features. For now, I've picked some reasonable values for the
CPUs that are most commonly used in practice. (Values are sourced from LLVM.)
The whole motivation behind this proposal in the first place was that
the LLVM backend disagrees with the self-hosted backends on what
`@setAlignStack` meant, so we can't just translate the old logic to the
new system! These backends can introduce support for overriding
`incoming_stack_alignment` later on.
These only worked before because our lowering of the `AAPCS` calling
convention was incorrect in a way which happened to match the ABI of
these functions. The tests aren't actually very helpful -- there are
already tests for `divmoddi4` etc -- so rather than using inline asm on
the caller side to match the ABI, we just delete these two tests.
We were for some reason missing a direct test for `__udivmodsi4`, so one
has been added.
There are several more that we could support here, but I didn't feel
like going down the rabbit-hole of figuring them out. In particular,
some of the Clang enum fields aren't specific enough for us, so we'll
have to switch on the target to figure out how to translate-c them. That
can be a future enhancement.
This commit finishes implementing #21209 by removing the
`@setAlignStack` builtin in favour of `CallingConvention` payloads. The
x86_64 backend is updated to use the stack alignment given in the
calling convention (the LLVM backend was already updated in a previous
commit).
Resolves: #21209
The old `CallingConvention` type is replaced with the new
`NewCallingConvention`. References to `NewCallingConvention` in the
compiler are updated accordingly. In addition, a few parts of the
standard library are updated to use the new type correctly.
As well as being necessary for the `CallingConvention` changes, this
update includes the following notable changes:
* Fix unlabeled `break` targeting the wrong scope in the presence of
labeled continue, unblocking #21422
* Implement `@FieldType`
* Implement `@splat` on arrays
Signed-off-by: mlugg <mlugg@mlugg.co.uk>
This commit begins implementing accepted proposal #21209 by making
`std.builtin.CallingConvention` a tagged union.
The stage1 dance here is a little convoluted. This commit introduces the
new type as `NewCallingConvention`, keeping the old `CallingConvention`
around. The compiler uses `std.builtin.NewCallingConvention`
exclusively, but when fetching the type from `std` when running the
compiler (e.g. with `getBuiltinType`), the name `CallingConvention` is
used. This allows a prior build of Zig to be used to build this commit.
The next commit will update `zig1.wasm`, and then the compiler and
standard library can be updated to completely replace
`CallingConvention` with `NewCallingConvention`.
The second half of #21209 is to remove `@setAlignStack`, which will be
implemented in another commit after updating `zig1.wasm`.
* fix compilation errors for fs and fs.Dir
* mem.span instead of mem.sliceTo
* Updating symLinkAbsoluteW function parameters
* Update with expected rename semantics
These are really answering questions about the Zig compiler's capacity to
provide a libc/libc++ implementation. As such, std.zig.target seems like a more
fitting place for these.
