See related discussion: KhronosGroup/OpenCL-CTS#1548

In short, the OpenCL SPIR-V environment spec currently does not describe the required accuracy for the OpFMod and OpFRem instructions (although it does describe the required accuracy for the fmod and remainder extended instructions).

OpenCL SPIR-V environment spec reference:

https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_ulp_values_for_math_instructions_full_profile

The spirv_new CTS tests are currently testing that OpFMod and OpFRem matches the behavior of these OpenCL C instructions, which may or may not be correct:

#define spirv_frem(a, b) fmod(a, b)              
#define spirv_fmod(a, b) copysign(fmod(a,b),b)  

For Vulkan, the accuracy of OpFMod and OpFRem is derived from trunc and floor, which makes them cheap but potentially highly inaccurate:

https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#spirvenv-op-prec

The OpFRem and OpFMod instructions use cheap approximations of remainder, and the error can be large due to the discontinuity in trunc() and floor(). This can produce mathematically unexpected results in some cases, such as FMod(x,x) computing x rather than 0, and can also cause the result to have a different sign than the infinitely precise result.

What do we want to do for OpenCL?