* Add `.llvmbc`/`.llvmir` to `ObjectFormat` for emitting unoptimized IR
* Replace `--verbose-air`, `--verbose-intern-pool`,
`--verbose-generic-instances`, `--verbose-llvm-ir`, and
`--verbose-llvm-bc` with various `--debug-log` scopes
* `--debug-log illegal-air`: pre-legalized Air
* `--debug-log legal-air`: post-legalized Air
* `--debug-log air`: final Air with liveness
* `--debug-log ip-stats`: InternPool statistics
* `--debug-log ip-values`: InternPool values
* `--debug-log ip-generic-instances`: InternPool generic instances
* `--debug-log llvm-ir`: pre-optimized LLVM IR
* `--debug-log opt-llvm-ir`: post-optimized LLVM IR
* Delete `--verbose-cimport` which does nothing
* Delete `--verbose-llvm-cpu-features` which is equivalent to looking at
the outputs of `--show-builtin` and `--debug-log llvm-ir`
This demonstrates one of the downsides of the approach in this branch:
since `zig build` CLI is intentionally unaware of the command line
parsing that will be done by the child process, it cannot obtain zig lib
dir override from the command line even as it needs that information in
order to build the subcommand.
Consequently, zig lib dir has to be passed via env var. CMake does not
provide a way to do this. So instead we rely on Zig's automatic lookup
functionality.
This could be mitigated by adding CLI arg parsing that happens *before*
the subcommand. I find this kind of special case to be awkward and
unpleasant however. I think it's better to simply remove the ability to
pass `--zig-lib-dir` to `zig build`.
- plain old data ftw
- 177K -> 151K
- data bypasses Sema
This change is not really important but it was nice to explore best
practices for data like this.
When I measured building the compiler, I found no statistically
significant difference in compilation time.
The C backend has always gleefully violated C's strict aliasing rules,
and I just got bitten by it for the first time when bootstrapping on
macOS. This probably hasn't been helping with some of the weird
bootstrap-related CI failures we've seen. So, update `bootstrap.c` and
`CMakeLists.txt` to tell GCC/Clang to disable type-based alias analysis.
No change is needed to the MSVC flags because MSVC does not, and never
has, implemented TBAA.
GCC bug 119085, which affects versions 13.0--15.1, is being triggered by
the C backend, resulting in a (small but critical) miscompilation in
zig2. Unfortunately, we can't really work around that bug without a
command-line flag, because the bug is sensitive to things like the order
in which `struct` types are defined.
Therefore, I have added an option to `bootstrap.c` which causes it to
pass the appropriate flag to `gcc` to disable the optimization pass in
question. This flag can likely be removed in future, once the affected
GCC versions become less common.
At least one of our x86_64-linux CI machines is using an affected GCC
version, so I also updated the relevant CI script to pass this flag when
testing no-LLVM bootstrap.
CMakeLists also has a workaround, but no user intervention is required
there: the GCC version range is automatically detected by CMakeLists.
Modifies the `Allocator` implementation provided by `ArenaAllocator` to be
threadsafe using only atomics and no synchronization primitives locked
behind an `Io` implementation.
At its core this is a lock-free singly linked list which uses CAS loops to
exchange the head node. A nice property of `ArenaAllocator` is that the
only functions that can ever remove nodes from its linked list are `reset`
and `deinit`, both of which are not part of the `Allocator` interface and
thus aren't threadsafe, so node-related ABA problems are impossible.
There *are* some trade-offs: end index tracking is now per node instead of
per allocator instance. It's not possible to publish a head node and its
end index at the same time if the latter isn't part of the former.
Another compromise had to be made in regards to resizing existing nodes.
Annoyingly, `rawResize` of an arbitrary thread-safe child allocator can
of course never be guaranteed to be an atomic operation, so only one
`alloc` call can ever resize at the same time, other threads have to
consider any resizes they attempt during that time failed. This causes
slightly less optimal behavior than what could be achieved with a mutex.
The LSB of `Node.size` is used to signal that a node is being resized.
This means that all nodes have to have an even size.
Calls to `alloc` have to allocate new nodes optimistically as they can
only know whether any CAS on a head node will succeed after attempting it,
and to attempt the CAS they of course already need to know the address of
the freshly allocated node they are trying to make the new head.
The simplest solution to this would be to just free the new node again if
a CAS fails, however this can be expensive and would mean that in practice
arenas could only really be used with a GPA as their child allocator. To
work around this, this implementation keeps its own free list of nodes
which didn't make their CAS to be reused by a later `alloc` invocation.
To keep things simple and avoid ABA problems the free list is only ever
be accessed beyond its head by 'stealing' the head node (and thus the
entire list) with an atomic swap. This makes iteration and removal trivial
since there's only ever one thread doing it at a time which also owns all
nodes it's holding. When the thread is done it can just push its list onto
the free list again.
This implementation offers comparable performance to the previous one when
only being accessed by a single thread and a slight speedup compared to
the previous implementation wrapped into a `ThreadSafeAllocator` up to ~7
threads performing operations on it concurrently.
(measured on a base model MacBook Pro M1)
- delete std.Thread.Futex
- delete std.Thread.Mutex
- delete std.Thread.Semaphore
- delete std.Thread.Condition
- delete std.Thread.RwLock
- delete std.once
std.Thread.Mutex.Recursive remains... for now. it will be replaced with
a special purpose mechanism used only by panic logic.
std.Io.Threaded exposes mutexLock and mutexUnlock for the advanced case
when you need to call them directly.
Our implementation did the classic add-sub rounding trick `(y = x +/- C =+ C - x)`
with `C = 1 / eps(T) = 2^(mantissa - 1)`. This approach only works for values whose
magnitude is below the rounding capacity of the constant. For a 64-bit mantissa
(like f80 has), `C = 2^63` only rounds for `|x| < 2^63`. Before we allowed this to
be ran on `e < bias + 64` aka `|x| < 2^64`. And because it isn't large enough,
we lose a bit to rounding.
For reference, the musl implementation does the same thing, using `mantissa - 1`:
https://git.musl-libc.org/cgit/musl/tree/src/math/ceill.c#n18
where `LDBL_MANT_DIG` is 64 for `long double` on x86.
This commit also combines the floor and ceil implementations into one generic one.
It has been observed in practice on powerpc64(le)-linux that zig.o (in various
stages and build modes) is large enough that the +/- 32MB branch range of
PowerPC is insufficient to reach from one end of the code section to the other.
With LLVM 21, this leads to silent miscompiles that then crash at runtime. With
LLVM 22, it will at least lead to branch range errors that fail the compilation,
but that gets us no closer to a working compiler.
By using these options, we give the linker much greater flexibility to move code
and data around to satisfy these range constraints; without them, the linker is
not allowed to split up the huge code and data sections of zig.o to do so.
Similar issues have also been observed on powerpc-linux (32-bit), hexagon-linux,
and some variations of mips(64)(el)-linux. But let's be conservative for now;
those other targets can be added to the condition later.
As a data point to support this change, it's worth noting that LLD started
enabling these options for LTO precisely because the resulting large compilation
units ran into these range issues. In some abstract sense, Zig can be seen as
doing a limited form of "LTO" in the frontend, so it's not surprising that we
would hit the same issues.
`__addosi4`, `__addodi4`, `__addoti4`, `__subosi4`, `__subodi4`, and
`__suboti4` were all functions which we invented for no apparent reason.
Neither LLVM, nor GCC, nor the Zig compiler use these functions. It
appears the functions were created in a kind of misunderstanding of an
old language proposal; see https://github.com/ziglang/zig/pull/10824.
There is no benefit to these functions existing; if a Zig compiler
backend needs this operation, it is trivial to implement, and *far*
simpler than calling a compiler-rt routine. Therefore, this commit
deletes them. A small amount of that code was used by other parts of
compiler-rt; the logic is trivial so has just been inlined where needed.
I also chose to quickly implement `__addvdi3` (a standard function)
because it is trivial and we already implement the `sub` parallel.
As with Solaris (dba1bf9353), we have no way to
actually audit contributions for these OSs. IBM also makes it even harder than
Oracle to actually obtain these OSs.
closes#23695closes#23694closes#3655closes#23693
There is no straightforward way for the Zig team to access the Solaris system
headers; to do this, one has to create an Oracle account, accept their EULA to
download the installer ISO, and finally install it on a machine or VM. We do not
have to jump through hoops like this for any other OS that we support, and no
one on the team has expressed willingness to do it.
As a result, we cannot audit any Solaris contributions to std.c or other
similarly sensitive parts of the standard library. The best we would be able to
do is assume that Solaris and illumos are 100% compatible with no way to verify
that assumption. But at that point, the solaris and illumos OS tags would be
functionally identical anyway.
For Solaris especially, any contributions that involve APIs introduced after the
OS was made closed-source would also be inherently more risky than equivalent
contributions for other proprietary OSs due to the case of Google LLC v. Oracle
America, Inc., wherein Oracle clearly demonstrated its willingness to pursue
legal action against entities that merely copy API declarations.
Finally, Oracle laid off most of the Solaris team in 2017; the OS has been in
maintenance mode since, presumably to be retired completely sometime in the 2030s.
For these reasons, this commit removes all Oracle Solaris support.
Anyone who still wishes to use Zig on Solaris can try their luck by simply using
illumos instead of solaris in target triples - chances are it'll work. But there
will be no effort from the Zig team to support this use case; we recommend that
people move to illumos instead.
Alex Rønne Petersen