| Issue |
87072
|
| Summary |
map `llvm.maxnum` to `NMax` instead of `FMax` and `llvm.minnum` to `NMin` instead of `FMin`
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
farzonl
|
FMax (Floating-Point Maximum):
- Result is y if x < y.
- If both x and y are zeros, either x or y is the result.
- If one operand is NaN (Not a Number), the result is the - other operand (the non-NaN operand).
- If both operands are NaN, the result is undefined.
NMax (NaN-Aware Maximum):
- Result is y if x < y.
- If both x and y are zeros, either x or y is the result.
- If one operand is NaN, the other operand is the result.
- If both operands are NaN, the result is NaN.
```
FMax is undefined if one of the operands in NaN, so in DXC we use NMax to match HLSL max. It looks like that matches the LLVM instrinsic semantics, so I think this will be a straightforward SPIR-V backend change, but we do have to check that it doesn't break anything for the OpenCL side.
```
_Originally posted by @sudonatalie in https://github.com/llvm/llvm-project/pull/86844#discussion_r1543515572_
This issue is to track the work to `SPIRVInstructionSelector.cpp` and make sure changing the `TargetOpcode` to `GL::FMin` `GL::FMax` doesn't break OpenCL.
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp#L433C1-L438C67
I suspect we will be able to change
```c++
...
selectExtInst(ResVReg, ResType, I, CL::fmin, GL::FMin);
...
selectExtInst(ResVReg, ResType, I, CL::fmax, GL::FMax);
```
to
```c++
...
selectExtInst(ResVReg, ResType, I, CL::fmin, GL::NMin);
...
selectExtInst(ResVReg, ResType, I, CL::fmax, GL::NMax);
```
without effecting openCL.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
