[m-rev.] for review: make many integer casts into builtins

[Julien Fischer]

Hi Zoltan,

On Thu, 24 May 2018, Zoltan Somogyi wrote:

> As far as this diff is concerned, there are several possible avenues for fixes.
>
> Option A is to simply not make the third category of operations into builtins.
> This is simple to do, but leaves performance on the table.
>
> Option B is to make the third category of operations into builtins only if the
> target machine is 64-bit. This is *far* from simple to do, because it means
> that whether a function is a builtin or not depends on the target platform,
> which means e.g. that we won't know whether to reject clauses for them.

Please do *not* do this.

> Option C is to generalize all three notions of cast in the compiler (in the LLDS,
> in the MLDS, and in builtin_ops.m itself) to include the source type as well
> as the destination type. This is a lot of work, in large part because it requires
> deciding what to do for sort-of-but-not-really sensible casts, such as casts
> straight from floats to uint16. (For obviously-not-sensible casts, such as
> float to type_info, an abort is obviously fine.)

We don't have casts from floats to ints.  If you want to convert
from a float to an int you need to use one of
{ceiling,floor,truncate,round}_to_int functions; having the conversion
require programmer to state how the fractional part of the float be
dealt with is a good thing in my view.

This raises another couple of issues: the documentation of those
functions (e.g. floor_to_int etc) is not about what happens in a number
of edge cases (e.g. if the argument won't fit in an int or is one of
the special floating point values).

The behaviour of the int->float conversion (i.e. float/1) is also
underspecified and prone to get a bit interesting at the edge cases.

> Option D: add MR_word_to_int64, its inverse and their uint64 variants
> as separate operations to builtin_ops.m. I am not sure yet whether they will need
> modifications to the LLDS and/or the MLDS rval types; the code generators
> should be able to implement them as a combination of box/unbox and cast operations.
>
> My preference is option D. What are your opinions?

I think D is fine.

Julien.