ashvardanian / ashvardanian/NumKong
Feature: Per-function target pragmas for LoongArch LASX kernels (blocked on GCC 15 / Clang 22 availability)
- Dominant language
- C
- Stars
- 1.9k
- Forks
- 130
- Avg merge
- 18h 28m
- Merged PRs (30d)
- 3
Description
### Describe what you are looking for
NumKong's x86, aarch64, and Power backends use per-function `__attribute__((target("..."))` / `#pragma GCC target("...")` annotations so each SIMD kernel scopes its own ISA requirement, and the translation-unit baseline stays at the ABI floor — giving runtime dispatch a clean contract where scaffolding code runs on any CPU matching the ABI. LoongArch is the outlier: the headers in `include/numkong/{cast,dot,set,spatial,scalar}/loongsonasx.h` carry no target annotations because GCC ≤ 14.2 and Clang ≤ 21 reject every form of the attribute on the LoongArch backend (empirically verified with `gcc-14-loongarch64-linux-gnu`: `warning: 'target' attribute is not supported on this machine`), and the bundled `lasxintrin.h` is preprocessor-gated on `__loongarch_asx` — a macro that only gets defined by TU-level `-mlasx`. As a result, `build.rs` / `CMakeLists.txt` / `setup.py` currently pin the LoongArch baseline to `-march=loongarch64 -mlasx`, meaning distributed LoongArch artifacts require LASX-capable hardware (LA464+, ~2021) even for scalar code paths that don't need it.
The upstream blockers are now resolved: GCC 15.1 (Feb 2025, r15-7523 closing PR target/118828) registers the attribute/pragma hooks in `gcc/config/loongarch/loongarch-target-attr.cc` and makes `__loongarch_asx` reactive to the pragma, and Clang 22.1 (May 2025, LLVM PR #140700) does the equivalent in `clang/lib/Basic/Targets/LoongArch.cpp`. Upstream testcases `gcc/testsuite/gcc.target/loongarch/la64/lasx-func-attr-1.c` and `clang/test/CodeGen/LoongArch/targetattr-lasx.c` confirm the exact per-function dispatch pattern we want. **Once these compilers reach broad distro availability** (Ubuntu 26.04 LTS / Debian 13 are likely the practical floor; Loongson already ships pre-built cross-toolchains via [loongson/build-tools](https://github.com/loongson/build-tools) for opt-in testing), this issue tracks: (1) bumping the LoongArch-specific minimum in `CONTRIBUTING.md` to GCC 15.1+ / Clang 22.1+, (2) annotating the `loongsonasx.h` kernel functions with `__attribute__((target("lasx")))` — matching the `#pragma GCC target("power9-vector")` pattern already used in `include/numkong/spatial/powervsx.h:50`, and (3) dropping `-mlasx` from the TU-level baseline so LoongArch artifacts run on any LA64 CPU, with runtime dispatch picking the LASX kernels only where the host supports them.
### Can you contribute to the implementation?
- [x] I can contribute
### Is your feature request specific to a certain interface?
C implementation
### Contact Details
_No response_
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Contributor guide
Research direction
Start with the LoongArch headers in include/numkong/{cast,dot,set,spatial,scalar}/loongsonasx.h and compare the per-function target pattern in include/numkong/spatial/powervsx.h:50. Check the GCC and Clang testcases named in the issue, then review build.rs, CMakeLists.txt, setup.py, and CONTRIBUTING.md. Done means the minimum compiler versions, annotations, and LoongArch baseline are updated so runtime dispatch can select LASX kernels without requiring LASX for all artifacts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- build-system, compilers, performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100