[BugFix] Reject unsupported fast-math input dtypes - #2804
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughFastmath intrinsics now validate frontend argument dtypes, accepting float and bfloat inputs while rejecting unsupported types. Parametrized tests cover rejection messages, returned call types, and dtype preservation. ChangesFastmath dtype validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
👋 Hi! Thank you for contributing to the TileLang project. Please remember to run We appreciate you taking this step! Our team will review your contribution, and we look forward to your awesome work! 🚀 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@testing/python/language/test_tilelang_language_fastmath.py`:
- Around line 19-36: Update test_fastmath_rejects_unsupported_dtype to include
int64 and uint64 in the parameterized dtype matrix, and strengthen the
pytest.raises match so it asserts the error includes the offending dtype via the
expected “but got {dtype}” text.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: aa5e6786-0008-4677-9c75-dcf6c8440296
📒 Files selected for processing (2)
testing/python/language/test_tilelang_language_fastmath.pytilelang/language/math_intrinsics.py
Summary
TypeErrorinstead of emitting identity operations or undefined CUDA symbolsRoot cause
The
T.__exp,T.__log, and related wrappers forwarded every input dtype directly to CUDA code generation. CUDA fast-math lowering only has valid paths for standard floating-point type codes: small integers and float8 fell through to an empty function name and became silent identity operations, while 32/64-bit integers emitted undefined CUDA symbols.The wrappers now use one shared validator matching TVM's floating-point type-code convention. Standard float and bfloat inputs retain their existing frontend behavior; unsupported types fail during intrinsic construction.
Fixes #2597.
Validation
.venv/bin/python -m pytest testing/python/language/test_tilelang_language_fastmath.py -q(88 passed).venv/bin/python -m pytest testing/python/math/test_math_fast_math.py testing/python/language/test_tilelang_language_dialect.py -q(18 passed, 34 skippedwithout a local GPU)python3 -m pre_commit run --files tilelang/language/math_intrinsics.py testing/python/language/test_tilelang_language_fastmath.pygit diff --checkSummary
__exp,__log,__tan,__cos,__sin,__exp10,__log2,__log10) using TVM floating-point type-code conventions.TypeErrors (while preserving existing behavior for float/bfloat inputs).tvm.tirx.Callwith matchingdtype).C++ style / lint notes
docs/developer_guide/cpp_style.mdand the “C++ API Style Audit (warning only)” CI step are not impacted by this PR.