Uses the new liveness behaviour. This also removes useless calls
to `processDeath` on branches that were just initialized. Branch
consolidation and processing deaths on branches inside `condbr`
is still a TODO, just like before.
This also skips var_args on other native backends as they do not
support this feature yet.
Backends want to avoid emitting unused instructions which do not have
side effects: to that end, they all have `Liveness.isUnused` checks for
many instructions. However, checking this in the backends avoids a lot
of potential optimizations. For instance, if a nested field is loaded,
then the first field access would still be emitted, since its result is
used by the next access (which is then unreferenced).
To elide more instructions, Liveness can track this data instead. For
operands which do not have to be lowered (i.e. are not side effecting
and are not something special like `arg), Liveness can ignore their
operand usages, and push the unused information further up, potentially
marking many more instructions as unreferenced.
In doing this, I also uncovered a bug in the LLVM backend relating to
discarding the result of `@cVaArg`, which this change fixes. A behaviour
test has been added to cover it.
This is a partial rewrite of Liveness, so has some other notable changes:
- A proper multi-pass system to prevent code duplication
- Better logging
- Minor bugfixes
Also remove an incorrect piece of logic which allowed fetching the 'len'
property on non-single-ptrs (e.g. many-ptrs) and add a corresponding
compile error test case.
Resolves: #4765
The issue with just passing `-gcodeview` is that it's not part of
the `OPT_g_Group` in `clang/Driver/Options.td`, so it doesn't trigger
debug info to be generated.
Passing only `-g` is sufficient on MSVC, as there is logic in `Clang.cpp`
which enables codeview if that is the default for the toolchain. Since
the default for -gnu is not codeview, we do pass `-gcodeview` in that case.
ccf670c made using `return` from within a comptime block in a non-inline
function illegal, since it is a use of runtime control flow in a
comptime block. It is allowed if the function in question is `inline`,
since no actual control flow occurs in this case. A few functions from
std (notably `std.fmt.comptimePrint`) needed to be marked `inline` to
support this change.
This pull request removes the optional allocator argument from functions
`divFloor` and `divTrunc`. As a result, the comments related to accepting an
optional `allocator` are no longer applicable. The support for accepting
an optional allocator was removed in #10017.
- Hold the lock for a shorter amount of time
- Previously, when holding the lock while signaling, the other, resumed
thread could potentially get suspended again immediately because
the mutex was still locked.
- Fix comment
- walk the stack via the method that is aware of unwind info (fixes x86_64 / aarch64 traces)
- enhance the output for frames where the debug info isn't available by printing the module name
This fixes `.INVAL => unreachable` being triggered by the cache system
on macOS when multiple processes race to create the same compilation.
The problem is that when two processes race to create a file, it
sometimes returns ENOENT even though that error code is nonsensical for
this situation.
Commit 2b0929929d67e222ca6a9523a3a594ed456c4a51 purportedly solved this,
but it did not open the file with write permissions, leading to the
EINVAL panic later on. This commit remedies the situation by introducing
a loop and simply retrying when the ENOENT occurs.
to avoid getting OOM killed. It's been happening regularly recently. We
need to have a high number of GitHub Actions runners simultaneously
active, otherwise the hardware ends up underutilized. But with zig build
running in parallel now, this sometimes results in memory usage spikes
that have been causing the runner to get killed.
This number is the total physical memory (126G) divided by the number of
runners we have active (6).
This reverts commit a34752c941c81e600c56670abb612fc86d0a2b73.
With #15277 merged, the macOS CI will still run the self-hosted x86_64
tests even with -Dskip-non-native. This was the main motivation for the
commit.
It would be nice to keep this flag enabled, however, we don't have
enough CI computing power, and the macOS CI lags behind with these extra
tests enabled.
