autotune: Code generator uses incorrect Triton math API paths, causing wasted iterations and final failure for gelu

[JosephNew]

Summary

When running autotune_kernel on the gelu operator, the code generator does not know the correct Triton API path for tanh, wasting 2 rounds on wrong APIs before finding the correct one in round 3 — but the final result still fails accuracy.

Steps to Reproduce

autotune_kernel(operator_name="gelu", target_speedup=1, max_rounds=3)

Actual Behavior

Round	Generated Code	Error
v1	tl.math.tanh(x)	AttributeError: module 'triton.language.math' has no attribute 'tanh'
v2	tl.libdevice.tanh(x)	AttributeError: module 'triton.language' has no attribute 'libdevice'
v3	from triton.language.extra import libdevice + libdevice.tanh(x)	Compiled but precision fails (max_diff ≈ 4.7e-4), only 5/12 tests pass

Additionally, the initial code generation also failed once (初始代码生成失败), meaning 4 attempts in total with no successful result.

Expected Behavior

The code generator should use the correct API from round 1:

from triton.language.extra import libdevice
result = libdevice.tanh(x)

Root Cause Analysis

1. Triton math.py (17 functions, NO tanh): exp, exp2, log, log2, cos, sin, sqrt, sqrt_rn, rsqrt, abs, fdiv, div_rn, erf, floor, ceil, fma, umulhi

   • Source: https://github.com/triton-lang/triton/blob/main/python/triton/language/math.py

2. Triton extra/libdevice.py (198 functions, INCLUDES tanh): Contains tanh, fast_tanhf, sinh, cosh, atan, asin, acos, and many more.

   • Source: https://github.com/triton-lang/triton/blob/main/python/triton/language/extra/libdevice.py

3. KernelGen generation prompts (kernelgen-generate.md, kernelgen-optimize.md, SKILL.md) contain zero guidance on Triton math API paths. The LLM relies entirely on its training data, which has inaccurate knowledge of the tanh API location in Triton.

Impact Scope

Any operator that depends on tl.math.tanh, tl.libdevice.*, or other math functions with ambiguous API paths (e.g., gelu, tanh, sigmoid, and other activation functions) may encounter similar issues.

Suggested Fix

1. Short-term: Add explicit Triton math API path guidance to the generation/optimization prompts — documenting which functions are in tl.math.* vs triton.language.extra.libdevice.*
2. Medium-term: Add an API availability check in the pre-check phase before compilation/testing, so API-missing errors are caught early without consuming iteration rounds

Test Environment

• Tool: autotune_kernel
• Operator: gelu
• Parameters: target_speedup=1, max_rounds=3
• Date: 2026-06-04

[Dongxu-H]

[JosephNew]

补充测试：API 路径盲区的系统性验证

对 8 个常见算子跑了 autotune（max_rounds=3），统计 V1 的 API 路径选择和行为。

测试结果

算子	V1 结果	V1 错误	最终结果	最终加速比
sigmoid	✅ 12/12	—	✅	0.67x
silu	✅ 10/10	—	✅	1.00x
atanh	✅ 6/6	—	✅	0.50x
tanh	❌ 0/11	tl.libdevice.tanh 不存在	✅ (3轮)	1.002x
pow	❌ 0/9	tl.math.pow 不存在	❌ 9/10 (3轮)	—
lgamma	❌ 0/6	tl.math.lgamma 不存在	✅ (2轮)	1.02x
acos	❌ 0/10	tl.acos 不存在	✅ (3轮)	1.02x
atan2	❌ 0/7	tl.math.atan2 不存在	✅ (3轮)	0.21x

分析

1. V1 错误模式一致

5/8 的算子在 V1 因 API 路径错误崩溃，分两类：

• 直接访问 tl.libdevice.xxx（无 import）：tanh、atan2(V2)
• 访问 tl.math.xxx（函数不在此模块）：pow、lgamma、atan2(V1)、acos(V2)

2. 能恢复，但有代价

• 多数算子在 2-3 轮后通过两种方式恢复：
  • 学会 from triton.language.extra import libdevice（lgamma、acos、atan2）
  • 用基础运算手动实现绕过（tanh、pow）
• 但恢复后的性能普遍较差：atan2 比 PyTorch 慢 5 倍（0.21x），tanh 几乎无提升（1.002x）
• pow 在 3 轮后仍未完全通过（fractional exponent 测试 NaN）

3. 没有跨算子学习

每个算子独立踩同一个坑（tl.libdevice / tl.math 路径错误），没有从历史错误中学习到正确的导入路径。

根因确认

代码生成器不知道 Triton math 函数的正确分布：

• triton.language.math 仅暴露约 17 个函数（sigmoid、exp、log、sqrt 等在列）
• triton.language.extra.libdevice 有约 198 个函数（tanh、pow、acos、atan2、lgamma 等在此）
• 生成器对不在 math 模块中的函数，首猜 tl.libdevice.xxx 或 tl.math.xxx，两者都是死路

影响评估

这不是阻塞性 bug（多数算子 3 轮内能恢复），但会导致：

1. 每个受影响算子浪费 1-2 轮迭代在 API 路径试错上
2. 手动绕过方案的性能通常不如直接调用 libdevice
3. 对复杂算子（如 gelu 同时依赖 tanh + erf），试错空间更大

建议在 prompt 或系统提示中显式告知生成器 Triton math 函数的正确导入路径。