Runtime `@shuffle` has two cases which backends generally want to handle
differently for efficiency:
* One runtime vector operand; some result elements may be comptime-known
* Two runtime vector operands; some result elements may be undefined
The latter case happens if both vectors given to `@shuffle` are
runtime-known and they are both used (i.e. the mask refers to them).
Otherwise, if the result is not entirely comptime-known, we are in the
former case. `Sema` now diffentiates these two cases in the AIR so that
backends can easily handle them however they want to. Note that this
*doesn't* really involve Sema doing any more work than it would
otherwise need to, so there's not really a negative here!
Most existing backends have their lowerings for `@shuffle` migrated in
this commit. The LLVM backend uses new lowerings suggested by Jacob as
ones which it will handle effectively. The x86_64 backend has not yet
been migrated; for now there's a panic in there. Jacob will implement
that before this is merged anywhere.
This adds 4 `Legalize.Feature`s:
* `expand_intcast_safe`
* `expand_add_safe`
* `expand_sub_safe`
* `expand_mul_safe`
These do pretty much what they say on the tin. This logic was previously
in Sema, used when `Zcu.Feature.safety_checked_instructions` was not
supported by the backend. That `Zcu.Feature` has been removed in favour
of this legalization.
We don't seem to be getting non-deterministic hangs since 4f3b59f, and e28b402
cut the run times significantly on top of that. Runs now seem to take around 1-2
hours, so the default timeout should be plenty.
This defines a WinMain() function that can be potentially problematic when it
isn't wanted. If we add back support for this library in the future, it should
be built separately from mingw32.lib and on demand.
Each target can opt into different sets of legalize features.
By performing these transformations before liveness, instructions
that become unreferenced will have up-to-date liveness information.
This is equivalent to `array_elem_val`, and doing that conversion in
Sema (seems reasonable since it's just a simple branch) is much easier
for the self-hosted x86_64 backend then actually handling this case.
Because we don't pass -fqemu and -fwasmtime on aarch64-linux, we're just
spending a bunch of time compiling all these module tests only to not even run
them. x86_64-linux already covers both compiling and running them.
Pointers to thread-local variables do not have their addresses known
until runtime, so it is nonsensical for them to be comptime-known. There
was logic in the compiler which was essentially attempting to treat them
as not being comptime-known despite the pointer being an interned value.
This was a bit of a mess, the check was frequent enough to actually show
up in compiler profiles, and it was very awkward for backends to deal
with, because they had to grapple with the fact that a "constant" they
were lowering might actually require runtime operations.
So, instead, do not consider these pointers to be comptime-known in
*any* way. Never intern such a pointer; instead, when the address of a
threadlocal is taken, emit an AIR instruction which computes the pointer
at runtime. This avoids lots of special handling for TLVs across
basically all codegen backends; of all somewhat-functional backends, the
only one which wasn't improved by this change was the LLVM backend,
because LLVM pretends this complexity around threadlocals doesn't exist.
This change simplifies Sema and codegen, avoids a potential source of
bugs, and potentially improves Sema performance very slightly by
avoiding a non-trivial check on a hot path.
In the case where a declaration has no type annotation, the interaction
between resolution of `nav_ty` and `nav_val` is a little fiddly because
of the fact that resolving `nav_val` actually implicitly resolves the
type as well. This means `nav_ty` never gets an opporunity to mark its
dependency on the `nav_val`. So, `ensureNavValUpToDate` needs to be the
one to do it. It can't do it too early, though; otherwise, our marking
of dependees as out-of-date/up-to-date will go wrong.
Resolves: #23959
In a compiler built with debug extensions, pass `--debug-incremental` to
spawn the "incremental debug server". This is a TCP server exposing a
REPL which allows querying a bunch of compiler state, some of which is
stored only when that flag is passed. Eventually, this will probably
move into `std.zig.Server`/`std.zig.Client`, but this is easier to work
with right now. The easiest way to interact with the server is `telnet`.
Reduced number of runners from 9 to 6.
This number is the total physical memory (251G) divided by the number of
runners we have active (6).
see previous commit 5b9e528bc550e7ea9e286fdd2324316f9895d5da
GitHub have introduced an absolutely baffling feature where users can
use Copilot to take their simple explanation of a bug, and reword it
into a multi-paragraph monologue with no interesting details and added
false information, while also potentially ignoring issue templates.
So far, GitHub has not provided a way to block this feature at the
repository or organisation level, so for now, this is the only way to
prevent users from filing LLM-generated slop.
Related: https://github.com/orgs/community/discussions/159749
The doc comment here agreed with the implementation, but not with *any*
`Step` which populates a `GeneratedFile`, where they are treated as
cwd-relative. This is the obvious correct choice, because these paths
usually come from joining onto a cache root, and those are cwd-relative
if not absolute.
This was a pre-existing bug, but #23836 caused it to trigger more often,
because the compiler now commonly passes the local cache directory to
the build runner process as a relative path where it was previously an
absolute path.
Resolves: #23954
37a9a4e accidentally turned paths `b/[hash]/` into `b[hash]/` in the
global cache. This doesn't technically break anything, but it pollutes
the global cache directory. Sorry about that one!
