Brilift: Float support

[sampsyo]

Not much to see here; this just adds support for the ever-popular floating point language extension in the Brilift compiler.

As always, there is a dangling annoyance here that different tools print floats differently. Currently, printf is currently only roughly within the ballpark of how Node and Rust print floats, so there are some niggling mismatches. A more tolerant way to match this stuff would be helpful, but I don't have any great ideas currently. Maybe some kind of fuzziness in Turnt, someday.

[sampsyo]

I think a good way to deal with the FP inconsistency stuff (in a separate PR) would be to just specify & require that all implementations use exactly 17 decimal digits of precision. We would bypass "friendly" printing modes that attempt to do aesthetically pleasing but still round-trippable rounding, as in Python >=3.1:

$ python3                                                                     ~
Python 3.9.13 (main, May 24 2022, 21:13:51) 
[Clang 13.1.6 (clang-1316.0.21.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 9/-20
-0.45
>>> '{:.17f}'.format(9/-20)
'-0.45000000000000001'

[Pat-Lafon]

Should other parts of floating point be specified as well, specifically how a compliant interpreter/runtime outputs Nan/Infinity? Are these only runtime values or should tools like bril2txt/bril2json be able to parse them as well?

[Pat-Lafon]

I am also interested in the following:

If there should be 2 additional operators to the floating point extension, isnan and isinf, which would match similar behavior as seen in Python. Though I guess that this could be implemented as a small function calls in a Bril program and then used via the import extension in the niche cases that would want them.

If Bril should allow conversion between integers and floating point values with an operator like toint/tofloat.

[sampsyo]

Yes, all that sounds right! Namely, specifying the output for NaN and infinity (doesn't matter what, but it doesn't have to match Node's defaults either) seems like a great idea. As does adding isnan and isinf, which match the behavior of math.h. This should be the plan. Conversion to/from integers seems pretty cool too.

Not sure about the text parser; that seems like a lower-order concern because the text format doesn't really have a spec. Agreement between implementations is nice anyway though, as you've experienced.

[Pat-Lafon]

Not sure about the text parser; that seems like a lower-order concern because the text format doesn't really have a spec. Agreement between implementations is nice anyway though, as you've experienced.

What I actually meant with that question is the following. In the canonical Bril JSON IR which one would provided to a compliant interpreter, is/should there be a way to provide the following.

{
  "functions": [
    {
      "instrs": [
        {
          "dest": "v0",
          "op": "const",
          "type": "float",
          "value": "NaN"
        }
      ],
      "name": "main"
    }
  ]
}

Or are values like NaN strictly something that can occur at runtime.

[sampsyo]

Got it; thanks for clarifying! To be clear, at the moment these are not allowed because NaN/infinite literals do not appear in JSON. I have no objection to extending the AST to allow these values in constants—no strong opinion either way, really.