Now that Big Sur does not have system libraries on the filesystem, zig can no longer read them and add them to the cache hash for the compiler id.
This changes it so that only the first library path returned by os_self_exe_shared_libs is added to the cache hash under Darwin. I looked into methods on getting the system version to keep parity with older versions, but @fengb reported that this works on Catalina (a version behind Big Sur)
Signed-off-by: Haze Booth <isnt@haze.cool>
This adds these two fields to a HashMap Entry:
uint32_t hash
uint32_t distance_from_start_index
Compared to master branch, standard library tests compiled 8.4% faster
and took negligible (0.001%) more memory to complete. The amount of
memory used is still down from before 8b82c4010480 which moved indexes
to be stored separately from entries.
So, it turns out, keeping robin hood hashing plus separating indexes
did result in a performance improvement. What happened previously is
that the gains from separating indexes balanced out the losses from
removing robin hood hashing, resulting in a wash.
This also serves as an inspiration for adding a benchmark to
std.AutoHashMap and improving the implementation.
The indexes are stored separately using an array of
uint8_t, uint16_t, uint32_t, or size_t, depending on the number of
entries in the map.
Entries only contain a key and a value, no longer have
distance_from_start_index or is_used.
In theory this should be both faster and use less memory.
In practice it seems to have little to no effect. For the standard
library tests, vs master branch, the time had no discernable
difference, and it shaved off only 13 MiB of peak rss usage.
This reverts commit 93f0bcb649087b5db5cfcba5de5faaaf59047751.
This is not correct (from #mingw-w64 IRC):
<andrewrk> is there no .def file for ntdll on arm 64 bit?
<andrewrk> or does mingw-w64-crt/lib64/ntdll.def apply to both x86_64
and aarch64?
<wbs> andrewrk: there's none at the moment (as apps rarely link directly
against ntdll, and I didn't want to guess needlessly around that one
originally when I added arm64 support, before I actually had a real
arm64 windows device)
<wbs> andrewrk: but I guess I could/should complete that now
<wbs> (if you need one right now, the libarm32 one probably is the
closest match)
* Take advantage of coercing anonymous struct literals to struct types.
* Reworks Module to favor Zig source as the primary use case.
Breaks ZIR compilation, which will have to be restored in a future commit.
* Decl uses src_index rather then src, pointing to an AST Decl node
index, or ZIR Module Decl index, rather than a byte offset.
* ZIR instructions have an `analyzed_inst` field instead of Module
having a hash table.
* Module.Fn loses the `fn_type` field since it is redundant with
its `owner_decl` `TypedValue` type.
* Implement Type and Value copying. A ZIR Const instruction's TypedValue
is copied to the Decl arena during analysis, which allows freeing the
ZIR text instructions post-analysis.
* Don't flush the ELF file if there are compilation errors.
* Function return types allow arbitrarily complex expressions.
* AST->ZIR for function calls and return statements.
One of the main motivating use cases for this language feature is
tracing/profiling tools, which expect null-terminated strings for these
values. Since the data is statically allocated, making them
additionally null-terminated comes at no cost.
This prevents the requirement of compile-time code to convert to
null-termination, which could increase the compilation time of
code with tracing enabled.
See #2029
Branch handling `*[N]T` to `E![]T` is already handled in a more complete
branch handling `*[N]T` to `[]T` *and* `*[N]T` to `E![]T` so it seems
safe to remove this one.
