Unboxed ints (int32, int64, and nativeint)
#1750
Conversation
antalsz
requested review from
riaqn,
ncik-roberts,
stedolan,
mshinwell,
poechsel,
gretay-js,
xclerc and
lukemaurer
as code owners
|
I'll read everything from |
There was a problem hiding this comment.
This is a partial review, but I've now timed out. (I've gone through files in the order presented on GitHub, skipping files that @mshinwell has offered to review. Stopped at unboxed_bits32s_alpha.ml.) I may be able to take a further look during the week, but it's more likely I will return to this in a week's time. @ccasin may take over.
This is needed to prevent unboxed ints from allocating
|
Incorrect allocation fixed, but I still need to respond to review |
Co-authored-by: Richard Eisenberg <[email protected]>
Co-authored-by: Richard Eisenberg <[email protected]>
Co-authored-by: Richard Eisenberg <[email protected]>
There was a problem hiding this comment.
This looks good! I read everything except the backend changes (which @mshinwell has said he will look at). Though I only skimmed the bits Richard had already reviewed (and while I tried to read all of the tests, I'm not claiming I really thought hard about the details of the three quickcheck implementations).
I'm holding off on clicking the approve button so we don't accidentally merge with the XXXs in there, but my comments are all minor.
A couple additional thoughts:
- As observed here and elsewhere, the duplication of the tests is a bit sad. Of course, not testing things is also a bit sad. We can divide the tests into a couple categories:
- For the runtime tests, I think having the copies is basically mandatory - this guards against copy-paste errors in the backend.
- For the typing tests, it's harder to imagine such an error now, considering how small the actual diff in
typingis here. But it's conceivable we'll decide to do different things with these layouts in the future (special treatment for small ints in arrays, for example). I think on balance I like having them, with a plan to replace them with some functor over abstract layouts in the far future. That will be a nice day.
- Should this just go straight into
layouts_beta? I think we've basically decided to stop using alpha for "normal" new layouts things, and reserve it for experimental or unusually risky things, and I suspect this falls into the former category. (If you agree, rather than copying things into the new beta tests, better to do what's done in the latest version of the float tests where there's one test file and the TEST stanzas just run the test at both flags, for tests expected to behave the same)
| (* XXX ASZ: What layouts version does this go with? *) | ||
| (* CR layouts XXX ASZ: Change [typ_int32] to fit in a 32-bit register, rather | ||
| than taking up a full 64-bit one. *) | ||
| let typ_int64 = if Arch.size_int = 4 then [|Int;Int|] else [|Int|] |
There was a problem hiding this comment.
Instead of having the complication of thinking about these multi-element arrays, I would just assert that Arch.size_int is 8. It is very unlikely it will ever be 4 again.
|
Now #2113 |
This adds unboxed integer support in the same vein as unboxed float support:
int32#,int64#, andnativeint#typesbits32,bits64, andwordlayoutsStdlib__Int32_u,Stdlib__Int64_u, andStdlib__Nativeint_umodulesThere's one standing issue: unboxed integers are still sometimes allocating with the closure and flambda middle-ends, but not the flambda2 middle-end, due to some inling failure. I'll be investigating that, but the rest should be reviewable.
Reviwers: @goldfirere or @ccasin