Purpose of G_FMINNUM/MAXNUM_IEEE

Code Generation
,
1

Hello All,

I came across these three GMIR opcodes with similar functionality(and slight differences, for eg: in terms on NaN handling) - G_FMINNUM, G_FMINNUM_IEEE and G_FMINIMUM.

Though we have the corresponding llvm intrinsics for G_FMINNUM(llvm.minnum) and G_FMINIMUM(llvm.minimum), we dont seem to have it for G_FMINNUM_IEEE.

And searching online, I found the G_FMINNUM_IEEE being used in AMDGPU target . Also, G_FMINNUM_IEEE is generated while lowering G_FMINNUM in LegalizerHelper.cpp.

Hence, wanted to understand,

  1. if the GMIR opcode G_FMINNUM_IEEE is still being used (or can be replaced)
  2. and whether there are any other users(backends) of this GMIR opcode.

Thank you,
Prerona

2

This is documented in llvm/docs/GlobalISel/GenericOpcode.rst and several other places. They differ in signaling nan and signed zero treatment. No, we can’t remove them and they are not redundant. We actually could use more variants of these opcodes with the full range of signed zero and signaling nan behaviors.

The name of the intrinsic was a mistake. We really should called them fmin/fmax, and additionally have minimum and maximum correspond to the _IEEE snan handling

3

Thanks for the response.
I am aware of its documentation for G_FMINMUM_IEEE, but

  1. since there is no llvm intrinsic for this(but present for the other min/max GMIR opcodes) and
  2. also IIUC, its quite similar to minimumNumber in IEEE-754:2019 except when input is sNaN

hence the question.

While exploring the uses of G_FMINNUM_IEEE(in upstream code), I could not find any instance where this GMIR opcode was directly used (except, like it was used while lowering G_FMINNUM) -

it seems that there is some proprietary code which is using it i.e some backend, which would like to handle sNaN (and propagate it as qNaN) ?

We actually could use more variants of these opcodes with the full range of signed zero and signaling nan behaviors.

I came across a similar comment by you (which was more than a year back).

May be its worth to rework/add the GMIR opcodes/intrinsics. (Will need to check, if there have been already efforts in this, but yeah, would be happy to contribute to the effort).

4

It is the IEEE behavior, which is what the AMDGPU instruction does. The llvm intrinsic is the libm behavior, so we need it to lower the generic intrinsic with additional snan quieting inserted