Use OpFUnordNotEqual for floating-point !=

[gnl21]

The normal IEEE not equal operation tests whether operands are unordered
or not equal (so comparison with a NaN returns true). This corresponds
to the SPIR-V OpFUnordNotEqual, so change to using that.

Fixes #2259

[johnkslang]

I think this proposes to make a != b the same as !(a == b). I think we should be quite careful about this. Is this backed up by the specification (or lack of detail enforcing NaN operation)? I even recall discussions that SPIR-V not even support the unordered compares, and one reason we did was for compiler transforms computing the ! of == and !=, but this seems to invalidate those arguments.

Do we need any specification changes for this?

[gnl21]

I think that this is justified by the current spec. It does propose to make a != b the same as !(a == b), but that's what's expected of the standard != operator in (all? most?) HLLs. It's a weird quirk of the naming convention that all IEEE comparisons convert to ordered comparison except !=, which naturally converts to the unordered version. The arguments about supporting the unordered comparisons (for <, >, ==, etc) apply in reverse to !=. There is no natural HLL expression of the ordered-not-equal, but we support it in SPIR-V to simplify compiler transforms.

For the purposes of ordered/unordered comparisons, any comparison involving a NaN is unordered. The definition of OpFUnordEqual says:

Floating-point comparison for being unordered or not equal.

which implies that, for OpFUnordNotEqual, x != NaN for all x. This matches C and D3D semantics. I'm not sure that GLSL says explicitly, but I think it is intended to match.

[gnl21]

Is there anything that I need to do to progress this?

[johnkslang]

Do we know if all IHVs are ready for this? At least it's been posted here for a while.

We also need to bump the code generation number since we are changing a code emission pattern. That will help protect against surprises too.

See:

// For low-order part of the generator's magic number. Bump up
// when there is a change in the style (e.g., if SSA form changes,
// or a different instruction sequence to do something gets used).
int GetSpirvGeneratorVersion()
{
    // return 1; // start
    // return 2; // EOpAtomicCounterDecrement gets a post decrement, to map between GLSL -> SPIR-V
    // return 3; // change/correct barrier-instruction operands, to match memory model group decisions
    // return 4; // some deeper access chains: for dynamic vector component, and local Boolean component
    // return 5; // make OpArrayLength result type be an int with signedness of 0
    // return 6; // revert version 5 change, which makes a different (new) kind of incorrect code,
                 // versions 4 and 6 each generate OpArrayLength as it has long been done
    // return 7; // GLSL volatile keyword maps to both SPIR-V decorations Volatile and Coherent
    // return 8; // switch to new dead block eliminator; use OpUnreachable
    return 9; // don't include opaque function parameters in OpEntryPoint global's operand list
}

(We are also in the middle of possibly migrating to a new method via @ben-clayton's PRs, e.g., #2277.)

[johnkslang]

BTW, it will be good to have the version bump in its own commit for ease of verification.

[gnl21]

Do we know if all IHVs are ready for this? At least it's been posted here for a while.

I don't know for certain, but this doesn't change the SPIR-V that drivers are being asked to accept, although it obviously changes the balance of how often these different opcodes come up. Both opcodes are currently tested in the CTS (OpFUnordNotEqual and OpFOrdNotEqual), so they should be working in implementations.

We also need to bump the code generation number

Sure, I'll do that now.