compiler: saturate float-to-int conversions

[niaow]

This works around some UB in LLVM, where an out-of-bounds conversion would produce a poison value.
The selected behavior is saturating, except that NaN is mapped to the minimum value.

Fixes #276

[aykevl]

The code itself looks reasonable, although I haven't studied it in depth.

Can you maybe add a few more test cases? I'm a little bit nervous around edge cases with floats, so for example I think it would be a good idea to test the values around the edges. You can look here for some examples: https://github.com/rust-lang/rust/blob/19e63bd50eb756e35416d7a8f01e2d63f419b373/src/test/run-pass/saturating-float-casts.rs

[aykevl]

Also, I'm not sure whether this was intentional but the behavior in this PR differs slightly from the LLVM builtin, which we'll probably want to use eventually: https://reviews.llvm.org/D54749. The builtin converts NaN to 0 instead of the minimal integer value. Using the same behavior would help with testing when we can use that builtin instead.

[niaow]

The builtin converts NaN to 0 instead of the minimal integer value.

Yeah, this was something I noticed. I had omitted the extra step to do this for signed integers as it seemed to be a bit of extra complexity for now, but I can add it in.

[aykevl]

I'm fine with it as it is. It just might need changing in the future.
The rationale for NaN to 0 conversion according to Rust is the following (source):

• Matches the behaviour of ARM’s vcvt instruction, making this have no overhead there.
• Should optimize reasonably well on other platforms.

I don't know whether softfloat implementations have the same behavior and whether LLVM optimizes this pattern, but at least in theory this pattern is cheap/free on ARM.

[deadprogram]

Thank you @niaow for the contribution and @aykevl for the review. Now merging.

[niaow]

This was. . . not ready to be merged

I guess I will open a new PR to actually finish this.

[deadprogram]

Oops, my bad. I misinterpreted the comments.