[0x12CC]

Certain users may expect corresponding SYCL and C++ standard-library math functions to produce matching results under floating-point compiler options. This PR makes the following changes to achieve these matching results:

1. Updates our <cmath> wrapper to define most functions inline so they're affected by the floating-point compiler flags.
2. Modifies code generation to treat certain __spirv_ocl_* functions as math built-ins. This preserves the existing behavior when accuracy requirements are specified for the functions.
3. Changes the <cmath> built-ins to match their equivalent SYCL built-ins when compiling device code. This includes enabling optimizations when compiling with the -ffast-math flag.
4. Removes an old test case that overrides a math function using a redefinition since it's not supported by the updated implementation.
5. Adds a test case that compares the numerical results of math built-in pairs for bitwise equality with various test input values.

[dm-vodopyanov]

@YuriPlyakhin, can you please review as part of dpcpp-spirv-reviewers team? This PR is targeted on the current release, and we would like to create cherry-picks to xmain and xmain-rel and merge them as well today

[YuriPlyakhin]

With -ffast-math, what happens when inputs produce Inf or NaN? Is it UB?
E.g. log(0.0), sqrt(-1.0), pow(1.0e30, 1.0e30), etc...
If it is UB, does it make sense to match results there?
Should cases like that be filtered out for the fast-math build?

[YuriPlyakhin]

nit

Please, consider storing the device output and the expected value and printing them in hex to make triaging failures easier.

[bashbaug]

Noting for completeness: there are also still some long-standing questions about the required accuracy for OpFMod and OpFRem, especially vs. the fmod and remainder extended instructions.

KhronosGroup/OpenCL-Docs#859

[bashbaug]

Thanks, LGTM!