Cuda Cutlass Fmha Incremental Rebuild

Incremental rebuilds silently use STALE CUTLASS fused-MHA kernels

> The general false-green principles (stale binary, wrong-artifact mtime) are summarised

> in the ort-test skill's "False-green taxonomy". This skill is the CUDA/CUTLASS-specific

> detail.

The gotcha (verification-integrity bug)

nvcc-generated depfiles do not track the CUTLASS fused-MHA headers under

onnxruntime/contrib_ops/cuda/bert/cutlass_fmha/ (e.g. kernel_forward.h,

fmha_launch_template.h). These headers are #included by the fmha_sm*.cu

translation units, but the build system does not record that dependency.

Consequence: after you edit one of those headers, an incremental build.sh:

• does not recompile fmha_sm*.cu,
• reports [100%] Built target ... and exits 0,
• leaves the recompiled artifacts — the fmha_sm*.cu.o objects and the

libonnxruntime_providers_cuda.so they link into — unchanged (same mtime as

the pre-edit build).

(Do not use the gtest test-exe mtime as the stale symptom: in the shared-provider

build the exe dlopens the .so and is not relinked, so its mtime stays old even

after a *correct* rebuild — see "How to confirm" below. The reliable diagnostic signal

is the fmha_sm*.cu.o / .so mtime.)

So your "successful" rebuild is running the old kernel. Tests that should now

pass (or fail) reflect the previous code, not your edit. This silently invalidates

any FAIL→PASS / PASS→FAIL verification.

The fix — force recompile the .cu units

Before rebuilding after editing any cutlass_fmha/*.h header:

touch onnxruntime/contrib_ops/cuda/bert/cutlass_fmha/*.cu

Then run the normal build command. This forces the fmha_sm*.cu translation units

(and downstream binaries) to recompile against your header change.

How to confirm the rebuild was real (don't trust "[100%] Built")

Confirm that the artifact which actually links the recompiled fmha_sm*.cu.o

is newer than your header edit.

⚠️ **Do NOT just check the test EXE mtime — it can falsely flag a good build as

stale.** In the shared-provider build configuration (the default here), the CUDA

execution provider is a shared module: the recompiled fmha_sm*.cu.o link into

libonnxruntime_providers_cuda.so, and the onnxruntime_provider_test executable

dlopens that .so — it is not relinked. So after a *correct* rebuild the

test exe mtime stays old while the .so advances. Checking the exe alone

would wrongly conclude the build was stale.

Check the right artifact for your link mode:

• Shared-provider build (default): the .so that links the recompiled .o —

build/<dir>/<cfg>/libonnxruntime_providers_cuda.so

• Statically-linked provider: the test exe itself (onnxruntime_provider_test)

Safest check — stat both the recompiled object and the .so, and confirm BOTH

are newer than the header edit:

stat -c '%y %n' onnxruntime/contrib_ops/cuda/bert/cutlass_fmha/kernel_forward.h
# in your build dir, e.g. build/Debug_quickbuild/Debug/:
stat -c '%y %n' libonnxruntime_providers_cuda.so
# and the actual recompiled object (path varies by build dir):
find . -name 'fmha_sm80.cu.o' -exec stat -c '%y %n' {} +

If the .so (and the fmha_sm*.cu.o) timestamps are older than (or equal to) the

header edit, the build was stale — touch the .cu files and rebuild. The most

reliable signal of all is behavioral: a test that was failing now passes (a stale

binary cannot flip its result).

Related: pick the right test binary

This is the CUDA/CUTLASS instance of false-green mode 1 (zero-match / wrong binary) —

see the ort-test skill's "False-green taxonomy" for the general principle. In short:

attention/MEA/Flash boundary gtests (e.g. FlashStructuralEmptyRows*,

Attention_Causal_NonPadKVSeqLen_MEA_*) live in onnxruntime_provider_test, which CI

runs; onnxruntime_test_all does not contain them and gives a false green. Verify the

MEA/Flash boundary fix against onnxruntime_provider_test.

Related: disk frugality on shared GPU dev boxes

Full ORT CUDA builds are large (test binaries ~1 GB each; a build dir can reach

tens of GB). On a shared box, /home filling to 100% makes builds fail in

non-obvious places — e.g. git submodule sync reporting No space left on device

or a config.lock error, not an obvious "disk full" at the compile step.

Before a big rebuild, check free space and clean only clearly-stale, regenerable

build directories (old dated experiment dirs). Never delete another agent's active

build dir or anything ambiguous:

df -h /home
du -sh build/* | sort -h