[Mesa-dev] [PATCH v3 134/133] nir/opcodes: Add algebraic properties metadata

[Matt Turner]

On Fri, Dec 19, 2014 at 5:04 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> v3: fmin and fmax technically aren't commutative or associative.  Things
>     get funny when one of the arguments is a NaN.

I have a difficult time believing that the GLSL definitions of min()
and max() intentionally have that effect.

To recap, the definition of min() in GLSL is

> Returns y if y < x, otherwise it returns x.

and since comparisons against NaN are always false, min(x, y) where x
or y is NaN will always return x, regardless of which argument is NaN.
That doesn't seem like a useful behavior.

Indeed the GLSL spec says

> Operations and built-in functions that operate on a NaN are not required to return a NaN as the result.

I think based on that text alone, min() and max() should be considered
commutative and associative.

Ian, perhaps we should clarify this with Khronos?

An IEEE 754 spec draft [1] defines minNum(x, y) as "y if x<y, x if
y<x, the canonicalized floating-point
number if one operand is a floating-point number and the other a NaN.
Otherwise it is either x
or y."

i965's SEL instruction implements that behavior.

[1] http://754r.ucbtest.org/drafts/archive/2006-10-04.pdf