LLVM's generic_la64 model is clearly biased towards Loongson's current offerings
rather than actually reflecting a generic model in the architectural sense. So
fix it up on our side.
- Emitting `OpCapability` and `OpExtension` from assembly is no longer allowed (tbh it never was because we silently ignored them).
They now `fail` with a message pointing users at `-mcpu`.
- `tools/gen_spirv_spec.zig` now also emits `Extension` and the `Capability.dependencies()`.
Also To keep the feature set a reasonable size, the generator filters to an allowlist of `KHR` and `EXT` entries.
We can decide which vendors to allow later if a use-case is found.
- `tools/update_cpu_features.zig` now uses the generated `spec.zig` and emits a feature for every
capability and extension, with the capability's `.deps` populated from `Capability.dependencies()`.
- `Module.finalize`, `Module.entryPoints`, `Module.addCapability`, `Module.addExtension`
and `sections.capabilities`/`sections.extensions` are deleted.
- Linker now verifies that an `.spv` object declares the `Linkage` capability
Adds target info for the PSX. Builds fine with the following:
```zig
const target = b.resolveTargetQuery(.{
.os_tag = .psx,
.cpu_arch = .mipsel,
});
```
the only "problem" being that it spits out an error from LLVM even
though generating an object file succeeds:
```sh
❯ zig build
install
└─ install generated to main.o
└─ compile obj obj Debug mipsel-psx failure
error: warning: MIPS-I support is experimental
```
Rename `wait` to `await` to be consistent with Future API. The
convention here is that this set of functionality goes together:
* async/concurrent
* await/cancel
Also rename Select `wait` to `await` for the same reason.
`Group.await` now can return `error.Canceled`. Furthermore,
`Group.await` does not auto-propagate cancelation. Instead, users should
follow the pattern of `defer group.cancel(io);` after initialization,
and doing `try group.await(io);` at the end of the success path.
Advanced logic can choose to do something other than this pattern in the
event of cancelation.
Additionally, fixes a bug in `std.Io.Threaded` future await, in which it
swallowed an `error.Canceled`. Now if a task is canceled while awaiting
a future, after propagating the cancel request, it also recancels,
meaning that the awaiting task will properly detect its own cancelation
at the next cancelation point.
Furthermore, fixes a bug in the compiler where `error.Canceled` was
being swallowed in `dispatchPrelinkWork`.
Finally, fixes std.crypto code that inappropriately used
`catch unreachable` in response to cancelation without even so much as a
comment explaining why it was believed to be unreachable. Now, those
functions have `error.Canceled` in the error set and propagate
cancelation properly.
With this way of doing things, `Group.await` has a nice property: even if
all tasks in the group are CPU bound and without cancelation points, the
`Group.await` can still be canceled. In such case, the task that was
waiting for `await` wakes up with a chance to do some more resource
cleanup tasks, such as canceling more things, before entering the
deferred `Group.cancel` call at which point it has to suspend until the
canceled but uninterruptible CPU bound tasks complete.
closes#30601
`std.Io.tty.Config.detect` may be an expensive check (e.g. involving
syscalls), and doing it every time we need to print isn't really
necessary; under normal usage, we can compute the value once and cache
it for the whole program's execution. Since anyone outputting to stderr
may reasonably want this information (in fact they are very likely to),
it makes sense to cache it and return it from `lockStderrWriter`. Call
sites who do not need it will experience no significant overhead, and
can just ignore the TTY config with a `const w, _` destructure.
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
* Remove the generic model; we already have generic_la32 and generic_la64 and
pick appropriately based on bitness.
* Remove the loongarch64 model. We used this as our baseline for 64-bit, but it's
actually pretty misleading and useless; it doesn't represent any real CPU and
has less features than generic_la64.
* Add la64v1_0 and la64v1_1 models.
* Change our baseline CPU model for 64-bit to be la64v1_0, thus adding LSX to
the baseline feature set.
This will mainly be used when targeting our wasm2c implementation which has no
problem with zero-length bulk memory operations, as a non-standard extension.
See: https://github.com/WebAssembly/tool-conventions/pull/235
This is not *quite* using the same features as the spec'd lime1 model because
LLVM 19 doesn't have the level of feature granularity that we need for that.
This will be fixed once we upgrade to LLVM 20.
Part of #21818.
Alex Rønne Petersen