Add value<->native_pointer intrinsics

[TheNumbat]

Implements builtins caml_native_pointer_of_value and caml_native_pointer_to_value.

I've confirmed this passes the tests in my version of the intrinsics library.

[gretay-js]

I think we may need to update Selectgen.oper_result_type

[xclerc]

Wouldn't the typing come from the external?

[gretay-js]

I think we may need to update Selectgen.oper_result_type

no, that's wrong.

[gretay-js]

@TheNumbat you were right, we do need some conversion operation in Cmm.transl_builtin because the type changes between int and val need to be recorded (to correctly hanlde them in the frametable). We should add Cmm.valuofint and Cmm.intofval (similar to Cmm.intoffloat and inttofloat) and the important case to implement is in Selectgen.oper_result_type.

[TheNumbat]

I added valueofint and intofvalue throughout the backend, and confirmed it still works with my updated intrinsics. They're mostly handled like intoffloat and floatofint, but are treated like opaque_identity for the purposes of register allocation and code emission.

I don't have a test case checking that this fixes an issue with frametable handling, though, so not entirely sure if this is what we want yet. Can someone suggest how to test that?

Also, the upstream build CI check fails now - how should I apply these changes to ocaml/?

[gretay-js]

Looks good, I just have a few comments.

1. Please make the PR "ready for review" (not draft).
2. fixing 32-bit builds: the new operations should only be added in backend subdirectory, don't don't change anything in ocaml/asmcomp
3. adjust testsuite/tool/parsecmm.mly and lexcmm.mll (it is probably not necessary for the tests in testsuite/tests/asmgen/ to pass because they don't use the new primitives yet, but adding a little test there would be nice).
4. we don't need to add clambda primitives, there should be no changes in middle_end subdirectory. The only way the new operations can be created is via the new intrinsic. So, no need to change cmmgen.ml either (only cmm_helpers.ml).
5. update backend/CSEgen similarly to floatofint and intoffloat (it's missing probably because warning 8 exhaustive match isn't on in that file).
6. No need to expose the new functions in cmm_helpers.mli, they are not used outside of cmm_helpers.ml

[mshinwell]

Hmm I don't understand the middle_end/ changes in this PR; are they needed?

[gretay-js]

Hmm I don't understand the middle_end/ changes in this PR; are they needed?

I don't think so, I also have a comment about it.

[TheNumbat]

I've addressed the comments, though I believe backend/CSEgen.ml was already updated (?).

[gretay-js]

I've addressed the comments, though I believe backend/CSEgen.ml was already updated (?).

yes, I somehow missed it, sorry.

(large update)

[xclerc]

I don't have a test case checking that this fixes an issue with frametable handling, though, so not entirely sure if this is what we want yet. Can someone suggest how to test that?

I don't have a good way to test that, and it is a bit worrying
indeed. Looking at the contents Xyz__frametable is both
not user-friendly and brittle. For this particular PR, I wonder
whether is would be enough to emit the Reg.typ field when
dumping for instance -dlinear.

[gretay-js]

I don't have a good way to test that, and it is a bit worrying indeed. Looking at the contents Xyz__frametable is both not user-friendly and brittle. For this particular PR, I wonder whether is would be enough to emit the Reg.typ field when dumping for instance -dlinear.

We can already see from -dlinear if a live set before a call has "val" or not (the "val"s are starred). For now, I think we should at least add the test in my comment above (which was resolveD) to the tests in ocaml_intrinsics library.

[xclerc]

I am not sure that appears everywhere,
for instance when spilling(misunderstood
was you wrote), but indeed that might be
enough for now.

Although, fundamentally, having a way
to output in a user-friendly fashion the
frame table of a function would probably
be useful. Possibly even for #797.

[xclerc]

(to be clear, I am not saying that
should happen in this very PR.)

[xclerc]

The purity-related changes should happen
in this PR, but the rest can be delayed.

[gretay-js]

The current version looks good to me.

[xclerc]

The arm64 concern should be addressed
(or proved wrong); the rest looks good.

[gretay-js]

The arm64 concern should be addressed (or proved wrong); the rest looks good.

@xclerc this has been addressed

[xclerc]

The code duplication introduced by the last commit
is a bit unfortunate, but can be addressed in another
pull request.