select statement that contains NaN value always returns NaN

[apartridge]

Hi.

I am trying to make a function that reads an input buffer (passed in as a Halide ImageParam, where the data is interleaved), and that returns NaN or 1, based on whether or not xyz[col, row, 0] is NaN. (Full reproducer below.)

xyz = ImageParam(
    type=Float(32),
    dimensions=3,
    name="xyz",
)
xyz.dim(0).set_stride(3)
xyz.dim(2).set_stride(1)

nan_or_one = Func("nan_or_one")
nan_or_one[col, row] = select(
    is_nan(xyz[col, row, 0]),
    f32(np.nan),  # This select always returns NaN. If this line is changed to f32(2.0) then it works as one expected, ie. 2.0 is returned when xyz[col, row, 0] is NaN, else 1.0 is returned.
    f32(1.0),
)

This select statement always returns NaN. If I change NaN to fex 2.0, then I get the expected output, ie. 2.0 when xyz[col, row, 0] is NaN, else 1.0. But for some reason the select statement does not handle NaN the same way as another float value.

Reproducer: https://gist.github.com/apartridge/2e652b7aceb80dfee67a4ca903e6bf90
Output with HL_DEBUG_CODEGEN=2: https://gist.github.com/apartridge/a3838c6a5ee43e7139bc246d7a97cc4b
Output with HL_DEBUG_CODEGEN=10000: https://gist.github.com/apartridge/902f0d1d3e75f230977cc3817719857b

I am using Halide 13 on Ubuntu 20 using the Python bindings. (I also see the problem on Halide 10.) I am using StrictFloat.

Note that this is simplified a bit compared to my original use case. What I want is to convert an input xyz buffer to an xyzw buffer, where I set w=1 if xyz is non-NaN, else set w=NaN.

This issue looks quite similar to #4213.

Also discussed on Gitter:
https://matrix.to/#/!cSNWpLyImSoNFJJFZE:gitter.im/$mZznBCmUdGov8_3Vsy05N2Fnc3-7AtZaeQUp_2mxJwg?via=matrix.org&via=gitter.im

Thanks for any assistance :)

[alexreinking]

This is actually a problem with our IRComparer stuff. It's considering nan and 1.0f to be equal.

[steven-johnson]

You will almost certainly need to compile this with strict_float to be reliable; by default, Halide compiles with the equivalent of -ffast-math, which (among other things) allows the code generators to assume that infinities and NaNs will never occur. That could be contributing to this issue.

[alexreinking]

@steven-johnson -- see my PR... this happens even when strict_float is enabled.

[apartridge]

Thanks for fixing this issue! Would it be possible to make a 13.0.5 release with this fix?