Use microarchitecture name instead of meaningless strings to name the core,
the legacy core is still retained.
1. Rename LOONGSONGENERIC to LA64_GENERIC
2. Rename LOONGSON3R5 to LA464
3. Rename LOONGSON2K1000 to LA264
Implement DYNAMIC_ARCH support for riscv64. Three cpu types are
supported, riscv64_generic, riscv64_zvl256b, riscv64_zvl128b.
The two non-generic kernels require CPU support for RVV 1.0 to
function correctly. Detecting that a riscv64 device supports
RVV 1.0 is a little complicated as there are some boards on the
market that advertise support for V via hwcap but only support
RVV 0.7.1, which is not binary compatible with RVV 1.0. The
approach taken is to first try hwprobe. If hwprobe is not
available, we fall back to hwcap + an additional check to distinguish
between RVV 1.0 and RVV 0.7.1.
Tested on a VM with VLEN=256, a CanMV K230 with VLEN=128 (with only
the big core enabled), a Lichee Pi with RVV 0.7.1 and a VF2 with no
vector.
A compiler with RVV 1.0 support must be used to build OpenBLAS for
riscv64 when DYNAMIC_ARCH=1.
Signed-off-by: Mark Ryan <markdryan@rivosinc.com>
- Updates to latest versions for all actions
- Pin actions not maintained by GitHub under `github.com/action` to exact
commit hashes. This is good practice for security, since tags can be
moved and then arbitray new code may execute. Since updating commit
hashes is slightly more hassle, the trade-off made here is to trust
GitHub, but not third-party actions.
This should also solve the warnings about Node.js 16 actions being
deprecated that is currently visible on the log page when docs.yml
is executed.
The `group` expression ensures that the cancel-in-progress
behavior is to only cancel if a new commit is pushed to the PR for
which the job is running, not other PRs.
This is a fairly standard snippet, used also in CI jobs for NumPy
and other projects.
This is a follow-up to gh-4271. At the moment, when a contributor
pushes the latest `develop` to their own branch to bring their own
fork in sync with `main`, or if they push another branch, this triggers
30 CI jobs to run. Most will complete silently and only burn CPU
time unnecessarily. If there's a failure, this may result in unexpected
failure notifications. And the AWS Graviton3 run won't complete at all
and time out, since the Cirun hook will only work when triggered from
the main repo.
I noticed this because GitHub emailed me that it would disable the
nightly job because it hadn't changed for 3 months. It currently takes
30-50 minutes daily, and by default runs on all forks of the main
repository that have the relevant workflow yaml file. That serves little
purpose and wastes quite a bit of energy - so disable the runs outside
of the main repo.
This will not disable the runs on forks already made in the past that
contain this workflow file, but it does save 3 months worth of runs on
every new fork that is created.
[skip ci]
Martin Kroeker