Define fmax/fmin/dmax/dmin opcode specifications

[r30shah]

I wanted to start a discussion around fmax/min and dmax/min IL Opcodes in OMR [1][2]. While working on one accelerating performance of sequence we would generate for code in OpenJ9 where we could leverage such opcodes, we did run into questions involving the specifications for such opcode. Especially how would we handle special cases where operand are signed zero or NaN values. [3]. OMR do not formally define specification for such opcode.

Should we follow IEEE-754 standard for these operations to standardize how to treat NaN / signed Zero? One concern with that would be the difference in how Java treats max / min operations and treats NaN value.

[1]. https://github.com/eclipse/omr/blob/6c6d6383ccd93937d1987de8e818a0a63118b01e/compiler/il/OMROpcodes.enum#L7944-L7975 [2]. https://github.com/eclipse/omr/blob/6c6d6383ccd93937d1987de8e818a0a63118b01e/compiler/il/OMROpcodes.enum#L8040-L8071 [3]. https://github.com/eclipse/omr/pull/7266#issuecomment-1989443524

[r30shah]

@0xdaryl I am not sure this is worthy of OMR architecture discussion, but I think atleast we should have some discussions.

FYI @sarwat12 / @hzongaro

[0xdaryl]

In my opinion, the default semantics of the OMR IL opcodes should be as broadly applicable to other language environments as possible. In this particular case, I'd say IEEE 754 semantics fits the bill. Variations in the IL opcode semantics in different language environments can be handled with frontend queries during operations such as constant folding, simplification, or code generation to do the right thing based on the requirements of a particular language. The frontend queries in OMR will answer all the questions as if it were following IEEE 754 semantics, and Java would potentially provide different answers.