Clean up some behavior of operator% (#1060)

Work on #1059

The `%` operator in the Slang implementation had several issues, and this change tries to address some of them:

* Renamed most occurences of "mod" describing this operator to be "rem" for "remainder" to better match its semantics in HLSL

* Split the operator into distinct integer and floating-point variants (`IRem` and `FRem`) to simplify having different codegen for the two

* Added floating-point variants of `operator%` and `operator%=` to the stdlib.

* Added custom C++ codegen for `kIROp_FRem` such that it maps to the standard C/C++ `remainder()` function

* Added custom GLSL codegen so that `kIROp_FRem` maps to the GLSL `mod()` function (which isn't correct...)

* Added a test case to confirm that D3D11, D3D12, and CPU targets all agree on the definition of floating-point `%`

* Fixed `render-test-tool` to allow a negative integer in a `data=...` specification. This didn't end up being used in the final test, but still seems like a good fix.

* Added a customized baseline for the Vulkan flavor of that test to confirm that we are *not* compiling correctly to SPIR-V just yet

Addressing the correctness of the output for GLSL/SPIR-V will have to come as a later change given that the operation we want is not exposed directly by unextended GLSL.

0 files changed, 0 insertions, 0 deletions