Conversation
fire-emblem
pushed a commit
to CompilerFans/DeepSelect
that referenced
this pull request
Sep 12, 2026
…is tree
Upstream names it `csrc/api.cpp` and builds it with `$cxx`; torch's
`CUDAExtension` routes a source by extension (`cpp_extension._is_cuda_file`:
`.cu`/`.cuh` to `$nvcc`, everything else to `$cxx`), so a `.cpp` means a second
compiler, a second flag list, a kerutils mode macro passed by hand, and `CXX`
pinned. This file is host code either way -- it has no `__global__` -- so
nothing about the *content* asks for a second compiler; only the suffix does.
Renaming it deletes that whole second path:
* the `"cxx"` bucket goes away (`-std=c++17`, `-DKERUTILS_IS_BUILD_ON_CUDA`,
and its own `-DDEEP_SELECT_NATIVE_ARCH`); `extra_compile_args` now passes
only `"nvcc"`, which is torch's name for "the device source list";
* `-DKERUTILS_IS_BUILD_ON_CUDA` is unnecessary rather than removed-in-spite-of:
mxcc defines `__MACA__` for a `.cu` and only for a `.cu` (measured with a
probe TU: `.cpp` -> undefined, `.cu` -> defined), and
`kerutils/common/common.h` keys that macro on `__CUDACC__ || __MACA__`;
* `mxcc -x maca` is the same switch, and measured to do the same thing
(`-x maca` before the input defines `__MACA__` for a `.cpp`). It cannot
reach this file through the build, though: `-x` is not a file type torch
knows, and the flag lists are per-bucket, not per-file. The suffix is the
selector.
`CXX` is a separate matter and stays pinned -- and it turns out the reason it
was pinned is not the one the comment gave. MACA's torch inherits a patch that
runs at *import*:
def set_wcuda_gnu_path(): # cpp_extension.py:62
gnu_path = os.path.join(CUDA_HOME, 'bin', 'gnu')
if os.path.exists(gnu_path):
os.environ['CXX'] = gnu_path
...
CUDA_HOME = _find_cuda_home() ...
set_wcuda_gnu_path() # :286
`get_cxx_compiler()` is just `os.environ.get('CXX', 'c++')`, so with the
default CUDA_HOME (cu-bridge, `_find_cuda_home`'s guess deepseek-ai#4) `CXX` is silently
repointed at cu-bridge's `bin/gnu`, a wrapper that execs mxcc. Reassigning
`cpp_extension.CUDA_HOME` does not undo it -- the patch already ran. It still
matters with every source as `.cu`, because ninja links with `$cxx`. Measured:
without the override the artifact's md5 changes (e5873cf8fcfb vs aff34b221e0d);
with it, the C500 extension is byte-identical to before this commit.
Not just a setup.py edit: `csrc/api.cpp` -> `csrc/api.cu` and the nine
references to the old name across `setup.py`, `CLAUDE.md`, `README.md`,
`deep_select/interface.py`, `csrc/structs.h`, `csrc/xcore1000/maca_topk.cu` and
the vendored `kerutils/device/device.cuh`.
Verification.
* xcore1000 (C500), the target this machine has: perf 95/95, correctness
200/200, 0 failures -- `./run_test.sh --all -nc` -- and the extension is
byte-identical (md5 aff34b221e0d).
* xcore1600 (C600/C600U), cold build, 53 TUs, 1m02s: `api.o` is built by
`cuda_compile` from `api.cu`; 10.1 MB extension; all 52
`run_topk_select_kernel` instantiations present and `PyInit_` exported;
loads under `spec_from_file_location` and exports
`get_alignment_requirement` / `topk`; `nm -D | grep
c10_cuda_check_implementation` empty, i.e. no torch-internal undefined
symbols (the host repo's rule).
Not verified: any runtime result on C600U. There is no xcore1600 hardware on
this machine, so the above is compile/link/load evidence only -- no shape was
executed on that architecture. That is the full extent of what can be checked
here, and no performance claim is made or implied for the ported kernel.
Co-Authored-By: Claude <noreply@anthropic.com>
fire-emblem
pushed a commit
to CompilerFans/DeepSelect
that referenced
this pull request
Sep 12, 2026
…_HOME
The build died on every invocation:
AssertionError: Error: no cu-bridge gnu found! Please ensure
cu-bridge is installed, 'CUDA_HOME' or 'CUDA_PATH' env is set to
cu-bridge directory.
`setup.py` pointed `cpp_extension.CUDA_HOME` at a directory it wrote
itself (`build/maca_cuda_home`) holding two of the three things torch
asks a MACA `CUDA_HOME` for -- `bin/nvcc` (its mxcc shim) and
`lib64/libcudart.so` -- and not the third, `bin/gnu`. torch's MACA
build calls `get_wcuda_gnu_path()` unconditionally from
`build_extensions` (`torch/utils/cpp_extension.py:1225`), and that
function reads the module global `CUDA_HOME` at call time, so it saw
the synthesized directory and found no `bin/gnu` in it.
`bin/gnu` is also the *only* return value of `get_cxx_compiler()` under
`USE_MACA` (`:420-427`) -- it ignores `CXX` entirely -- so the file's
`os.environ["CXX"] = "g++"` line was dead code: ninja's `$cxx` was
cu-bridge's `gnu` either way.
Stop synthesizing a home. `torch.utils.cpp_extension` on MACA is
written against cu-bridge: `_find_cuda_home()` lands on
`${MACA_PATH}/tools/cu-bridge` (its guess deepseek-ai#4), and `_join_cuda_home`
drives the device compiler as `$CUDA_HOME/bin/nvcc`, falling back to
`bin/cucc` when that path does not exist -- which is this install's
case. The default is what the toolchain is wired for, so the fix is to
leave it alone. `cucc` is the whole CUDA-dialect adapter, and the four
jobs the shim was reimplementing are its:
-imacros __macro_mxcc.h `__MACACC__` -> `__CUDACC__`/`__NVCC__`
-gencode=... -> mxcc does not take torch's `-gencode`
-DNV_ARCH_A100
-Xdevice -D__CUDA_ARCH__=
-lcudart -> -lmcruntime what MACA spells the CUDA runtime
-I ${MACA_PATH}/include/ the MACA library catalogue
{mcr,mcblas,...}
Everything cucc does not recognize it forwards unchanged to mxcc
(`-forward-unknown-to-compiler`), which is how the mxcc-dialect flags in
`compile_args` reach the compiler.
Deleted: `_MXCC_NVCC_WRAPPER`, `_prepare_mxcc_home`, `_HOST_CXX`, the
`CUDA_HOME` reassignment and the `CXX` write -- 140 lines out, 61 in,
most of the rest being the note above so the next person does not
reintroduce it.
Measured, this box (MACA 3.8.1.3, torch 2.10.0+metax3.8.1.0, g++ 11.4):
rm -rf build && ./build.sh
device compiler is .../tools/cu-bridge/bin/cucc
host compiler is .../tools/cu-bridge/bin/gnu
OK xcore1000 (xcore1000)
OK xcore1600 (xcore1600)
./install.sh rc=0, wheel installed
readelf -d deep_select_xcore1600*.so
NEEDED libmcruntime.so (no libcudart.so -- the
translation happened)
NEEDED libToolsExt_cu.so libruntime_cu.so libmcToolsExt.so
libmaca_mathlib_host.so libmccompiler.so
`install.sh` needs one repair of its own to get that far: it read the
built wheel with `unzip -l`, and `unzip` is not installed on this host,
so the check failed closed on a wheel that was fine. `python -m
zipfile -l` is the same listing and python is already required above it.
Gate results: the build, not the kernels. `./build.sh` for both
targets, `./install.sh` end to end, and the NEEDED list above. The
official slice is NOT a gate for this commit and is recorded instead:
`--backend maca_c` scores 4/200 on this C600U because `csrc/xcore1600/`
selects wrong on a 64-lane wave -- run to run, eight runs giving eight
distinct wrong index sets on an `arange` input. That is pre-existing and
recorded in CLAUDE.md's Known holes; the pre-cu-bridge artifact,
repaired with a `gnu` symlink so it builds at all, is wrong on every run
too and wrong differently each time (7 distinct in 8). Two different
`.so` md5s, same-source behavior under a toolchain change.
Architecture boundary: build plumbing only; no file under `csrc/` is
touched, so the kernels are byte-identical in source. What changed is
which toolchain translates the flags and which wrapper links them, and
both targets were rebuilt and inspected rather than inferred.
Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3.
Calling
topk()with input on a non-current GPU previously selected launch properties and a stream from the caller's current device. Mixed-device auxiliary and output tensors also passed validation.Install a scoped input-device guard before CUDA setup, select properties and the current stream for that device, and reject
end, output tensors, and index offsets on other devices. The guard restores the caller's device when the call returns or throws.Add behavioral tests for each mixed-device argument and a CUDA graph replay test that calls Top-K while another device is current. Changing the captured input before replay checks that the launch uses the input device's selected non-default stream.
Validation: C++20 syntax compilation of
csrc/api.cppand Python syntax compilation passed.