Name the real AITER kwargs in the dlopen hints

[demandal25]

Summary

The three dlopen-failure hints in aiter_loader.cc tell the reader to call an AITER entry point "with matching (dtype=..., is_causal=..., has_lse=...)". has_lse is not a parameter of any of them, so someone debugging a missing .so follows the hint and gets a TypeError rather than the JIT build they wanted. Raised as suppressed comments on #339 after it merged.

Verified against the installed amd-aiter 0.1.20 wheel rather than the review text:

mha_fwd                 aiter/ops/mha.py:209   return_softmax_lse: bool,
mha_varlen_fwd          aiter/ops/mha.py:933   return_softmax_lse: bool,
mha_batch_prefill_func  aiter/ops/mha.py:3885  return_lse=False,

dtype is the same defect one step further, which the review did not reach: it is not a keyword either — it comes from the q/k/v tensors. Relabelled q dtype so everything inside the parentheses is a real keyword and the next reader is not misled by a mixed list.

This is the second round of the same class on this file; #339 corrected causal vs is_causal. The cause is that the hint reads as prose while being a literal call recipe.

What changed

• csrc/rocm/aiter_loader.cc — has_lse= becomes return_softmax_lse= for the mha_fwd and mha_varlen_fwd hints and return_lse= for mha_batch_prefill_func; dtype= becomes q dtype= in all three. Error-message text only, no behaviour change.

Test plan

• Each keyword read off the installed 0.1.20 wheel in the ROCm 10.0 container, not from a source checkout.
• pre-commit run -a.
• No test covers these strings — they are the text of a std::runtime_error raised only when a variant .so is absent.

[Copilot]

Pull request overview

Updates the ROCm AITER loader’s dlopen-failure hint strings so they reference the actual AITER keyword arguments, avoiding misleading “copy/paste” call recipes that can throw TypeError instead of triggering AITER’s lazy JIT build.

Changes:

• Replace the non-existent has_lse= hint with return_softmax_lse= for mha_fwd / mha_varlen_fwd.
• Replace has_lse= with return_lse= for mha_batch_prefill_func.
• Relabel dtype= to q dtype= in all three hints to reflect that dtype is inferred from tensor inputs rather than passed as a keyword.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

csrc/rocm/aiter_loader.cc:194

• The hint now uses q dtype=..., which still reads like a Python keyword argument assignment (and even uses an =) even though the dtype comes from the q/k/v tensors. Consider changing this to a non-assignment form (e.g., q dtype: fp16) to avoid implying a callable kwarg.

    return "  Hint: trigger AITER's lazy JIT build by importing aiter.ops.mha and "
           "calling mha_varlen_fwd with matching (q dtype=" +
           std::string(key.dtype == VariantKey::Dtype::kFp16 ? "fp16" : "bf16") +

csrc/rocm/aiter_loader.cc:207

• The hint now uses q dtype=..., which still reads like a Python keyword argument assignment even though the dtype comes from the q/k/v tensors. Consider changing this to a non-assignment form (e.g., q dtype: fp16) to avoid implying q dtype is a kwarg.

        return "  Hint: trigger AITER's lazy JIT build by calling "
               "aiter.ops.mha.mha_batch_prefill_func() once with matching (q dtype=" +
               std::string(key.dtype == VariantKey::Dtype::kFp16 ? "fp16" : "bf16") +

[demandal25]

Suppressed comments, review 5073132011 (2) — same finding as the inline thread, fixed in 8b56e86a4: q dtype= becomes q dtype: in all three hints, so the = forms inside the parentheses are all real keywords.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.