Non-strict torch.export traces through torch_function and dispatcher/proxy machinery, so a raw Triton kernel launch is invisible as a stable export operator. The trace falls into Triton's runtime and the argument binder tries to specialize tensor arguments via data_ptr(), which fake/functional tensors cannot expose. Users then saw a generic data pointer failure instead of guidance for the supported Triton export path.
This keeps strict export behavior unchanged and rewrites only non-strict data_ptr failures that occur from Triton's runtime into an actionable error telling users to wrap the kernel in torch.library.triton_op and launch it through torch.library.wrap_triton or torch._library.capture_triton. A focused CUDA/Triton regression test covers the raw-kernel non-strict path, and the existing custom Triton export test covers the supported path.
Fixes #146066
Generated by my agent
Test Plan:
python test/export/test_export.py TestExport.test_export_raw_triton_kernel_non_strict_error
python test/export/test_export.py TestExport.test_export_custom_triton_kernel
lintrunner -a
Pull Request resolved: #185827
Approved by: https://github.com/zou3519, https://github.com/desertfire
SOCIAL SHARE CARD GENERATOR