[SYCL][NVPTX] Enable approximate div/sqrt with -ffast-math #15553
Conversation
The generation of approximate div/sqrt in the NVPTX backend is driven by the "unsafe-fp-math" function attribute, as there is currently no suitable instruction-level representation (flag, metadata, etc.) for this optimization. The problem with this function attribute is that when inlining it must be set on *both* caller/callee functions, otherwise it is wiped. Since CUDA's devicelib bytecode library has hundreds functions with unsafe-fp-math explicitly disabled, if we inline those functions into SYCL kernels, we disable the ability for the backend to generate approximate functions, not just inside the devicelib function but across the entire kernel. This might explain why some performance reports we've received suggest that inlining certain maths functions can make things worse even when the CUDA compiler does the same thing (e.g., intel#14358 though this needs verified). For this reason, presuambly, the NVPTX backend has two codegen options that override the function attribute and always generate approximate div/sqrt instructions. This patch thus explicitly sets these options when compiling SYCL for NVPTX GPUs. It does not do so for regular C/C++ or CUDA code to limit the wider impact on existing code.
frasercrmck
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
frasercrmck
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
|
I note that the AMDGPU backend treats the fast-math so my reading was that it's not intended for |
|
Ping @intel/dpcpp-clang-driver-reviewers |
Thanks for the review! Just to check - do you mean IR codegen or NVPTX codegen? There wouldn't be anything meaningful to check in LLVM IR because it doesn't affect the IR at all. The NVPTX codegen is tested elsewhere like here (div) and here (sqrt). So in short I think it's already covered? |
Yes, NVPTX codegen. Thanks! |
|
@intel/llvm-gatekeepers This is ready to merge, cheers |
The generation of approximate div/sqrt in the NVPTX backend is driven by the "unsafe-fp-math" function attribute. Presumably when the optimization was first added there was no way of getting at this information from ISel, or even that there was no suitable instruction-level representation to begin with.
Even today, the
afnfast-math flag is appropriate for relaxing sqrt to an approximate version, but while some targets apply that reasoning to fdiv, it's not clear that's a valid reading of the language reference manual.The problem with using the function attribute is that when inlining it must be set on both caller/callee functions, otherwise it is wiped.
Since CUDA's devicelib bytecode library has hundreds functions with unsafe-fp-math explicitly disabled, if we inline those functions into SYCL kernels, we disable the ability for the backend to generate approximate functions, not just inside the devicelib function but across the entire kernel.
This might explain why some performance reports we've received suggest that inlining certain maths functions can make things worse even when the CUDA compiler does the same thing (e.g., #14358 though this needs verified).
For this reason, presuambly, the NVPTX backend has two codegen options that override the function attribute and always generate approximate div/sqrt instructions. This patch thus explicitly sets these options when compiling SYCL for NVPTX GPUs. It does not do so for regular C/C++ or CUDA code to limit the wider impact on existing code.