Submit a TileLang Pull Request
Objective
Make the intended patch reviewable and CI-ready before it is pushed. A request
to inspect or test changes does not authorize committing, pushing, opening a PR,
or changing an existing PR. When updating an existing PR, push its current head
branch instead of opening a duplicate PR.
Inspect the Patch
- Check the worktree, branch, upstream, remotes, Git identity, PR head, and base.
Preserve unrelated edits and real changes inside
3rdparty/tvm.
- Review the complete diff against the PR base, not only unstaged changes.
Separate the intended fix from cleanup or generated files before staging.
- After switching branches or changing the TVM gitlink, align a clean TVM
submodule and rebuild before trusting tests that load native libraries. Never
overwrite a dirty submodule to make the checkout appear clean.
Audit Test Portability
Read the current CI matrix in .github/workflows/ci.yml. Do not assume a test
in a generic testing/python directory runs only on the backend used locally.
- Decide whether each added or changed test is portable or backend-specific.
Add
@tilelang.testing.requires_cuda, requires_rocm, or requires_metal
when it needs that backend's runtime, registered FFI passes, source syntax,
headers, intrinsics, or code generator.
- Explicit source-only lowering to a target such as
{"kind": "cuda", "arch": "sm_100a"} still requires the CUDA backend to be
built and registered. Mark it with requires_cuda even if no kernel runs.
- Use a
requires_cuda_compute_version* decorator when execution requires that
physical GPU capability. An explicit-architecture source-generation test
normally needs only requires_cuda.
- Do not infer CUDA exclusivity from a PyTorch tensor using
device="cuda";
PyTorch's ROCm build uses the same device spelling.
- Do not rely on auto-target selection while asserting backend-specific source.
Select the target explicitly and add its backend requirement.
- If only one assertion is target-specific, split it from portable lowering or
runtime coverage. Do not hide useful cross-backend coverage by marking a
whole file or broad test group.
- Before adding a skip marker to fix CI, confirm the failure is an unsupported
test contract rather than a real regression in a supposedly portable path.
Apply the requirement directly to every affected test, including parameterized
tests:
@tilelang.testing.requires_cuda
@pytest.mark.parametrize("op", ["sum", "max"])
def test_cuda_packed_codegen(op): ...
Validate the Current Head
- Load
tilelang-build when an install or rebuild is needed. Rebuild native
code after a branch checkout when the existing build may be stale.
- Run focused tests first, then the containing test file or suite. When
practical, verify that an unsupported backend skips a target-specific test
instead of failing during lowering, compilation, source inspection, or device
setup.
- Run
git diff --check and ./format.sh. Inspect every formatter change and
keep only changes that belong to the PR.
- Treat a green focused test as limited evidence. Report unrelated or
environment-specific containing-suite failures separately instead of claiming
that the whole suite passed.
- Reinspect the final staged diff and ensure the recorded validation matches
commands that actually completed successfully.
Commit, Push, and Verify
- Stage only the intended files and commit with the configured human identity.
Keep commit messages and public PR text free of automation traces and local
machine paths.
- Prefer the existing writable fork remote and never force-push without explicit
authorization. For an existing PR, verify its repository and head branch
before pushing.
- Write concise English PR text with specific bracketed component tags and list
only completed validation. Do not create a draft unless the user requests it.
- After pushing, verify that the PR's reported head SHA equals the pushed commit
and report newly triggered checks as pending, passing, or failing separately.
Do not wait for CI unless the user asks for monitoring.
1---2name: tilelang-submit-pr3description: Prepare, update, and submit TileLang pull requests with repository-specific CI readiness checks. Use when asked to commit, push, publish, open, or make an existing TileLang PR ready; covers scoped diffs, backend-aware test gating, build freshness, formatting, validation, and post-push verification. Do not use for ordinary local builds or test runs without PR intent.4---56# Submit a TileLang Pull Request78## Objective910Make the intended patch reviewable and CI-ready before it is pushed. A request11to inspect or test changes does not authorize committing, pushing, opening a PR,12or changing an existing PR. When updating an existing PR, push its current head13branch instead of opening a duplicate PR.1415## Inspect the Patch1617- Check the worktree, branch, upstream, remotes, Git identity, PR head, and base.18 Preserve unrelated edits and real changes inside `3rdparty/tvm`.19- Review the complete diff against the PR base, not only unstaged changes.20 Separate the intended fix from cleanup or generated files before staging.21- After switching branches or changing the TVM gitlink, align a clean TVM22 submodule and rebuild before trusting tests that load native libraries. Never23 overwrite a dirty submodule to make the checkout appear clean.2425## Audit Test Portability2627Read the current CI matrix in `.github/workflows/ci.yml`. Do not assume a test28in a generic `testing/python` directory runs only on the backend used locally.2930- Decide whether each added or changed test is portable or backend-specific.31 Add `@tilelang.testing.requires_cuda`, `requires_rocm`, or `requires_metal`32 when it needs that backend's runtime, registered FFI passes, source syntax,33 headers, intrinsics, or code generator.34- Explicit source-only lowering to a target such as35 `{"kind": "cuda", "arch": "sm_100a"}` still requires the CUDA backend to be36 built and registered. Mark it with `requires_cuda` even if no kernel runs.37- Use a `requires_cuda_compute_version*` decorator when execution requires that38 physical GPU capability. An explicit-architecture source-generation test39 normally needs only `requires_cuda`.40- Do not infer CUDA exclusivity from a PyTorch tensor using `device="cuda"`;41 PyTorch's ROCm build uses the same device spelling.42- Do not rely on auto-target selection while asserting backend-specific source.43 Select the target explicitly and add its backend requirement.44- If only one assertion is target-specific, split it from portable lowering or45 runtime coverage. Do not hide useful cross-backend coverage by marking a46 whole file or broad test group.47- Before adding a skip marker to fix CI, confirm the failure is an unsupported48 test contract rather than a real regression in a supposedly portable path.4950Apply the requirement directly to every affected test, including parameterized51tests:5253```python54@tilelang.testing.requires_cuda55@pytest.mark.parametrize("op", ["sum", "max"])56def test_cuda_packed_codegen(op): ...57```5859## Validate the Current Head6061- Load `tilelang-build` when an install or rebuild is needed. Rebuild native62 code after a branch checkout when the existing build may be stale.63- Run focused tests first, then the containing test file or suite. When64 practical, verify that an unsupported backend skips a target-specific test65 instead of failing during lowering, compilation, source inspection, or device66 setup.67- Run `git diff --check` and `./format.sh`. Inspect every formatter change and68 keep only changes that belong to the PR.69- Treat a green focused test as limited evidence. Report unrelated or70 environment-specific containing-suite failures separately instead of claiming71 that the whole suite passed.72- Reinspect the final staged diff and ensure the recorded validation matches73 commands that actually completed successfully.7475## Commit, Push, and Verify7677- Stage only the intended files and commit with the configured human identity.78 Keep commit messages and public PR text free of automation traces and local79 machine paths.80- Prefer the existing writable fork remote and never force-push without explicit81 authorization. For an existing PR, verify its repository and head branch82 before pushing.83- Write concise English PR text with specific bracketed component tags and list84 only completed validation. Do not create a draft unless the user requests it.85- After pushing, verify that the PR's reported head SHA equals the pushed commit86 and report newly triggered checks as pending, passing, or failing separately.87 Do not wait for CI unless the user asks for monitoring.