`Word8.toLargeInt` is broken in 32-bit version

[pclayton]

Version

110.99.4 (Latest)

Operating System

• Any
• Linux
• macOS
• Windows
• Other Unix

OS Version

Linux fedora 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Processor

• Any
• Arm (using Rosetta)
• PowerPC
• Sparc
• x86 (32-bit)
• x86-64 (64-bit)
• Other

System Component

Basis Library

Severity

Minor

Description

In 32-bit SML/NJ, Word8.toLargeInt does not give the correct result.

Transcript

[username@hostname sml]$ sml -32
Standard ML of New Jersey (32-bit) v110.99.4 [built: Fri Jan 26 09:05:35 2024]
- Word8.toLargeInt 0w0;
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
val it = 4149707864 : IntInf.int
- Word8.toLargeInt 0w1;
val it = 8444675160 : IntInf.int
- Word8.toLargeInt 0w2;
val it = 12739642456 : IntInf.int

Expected Behavior

> Word8.toLargeInt 0w0;
val it = 0: LargeInt.int

Steps to Reproduce

See transcript.

Additional Information

No response

Email address

phil.clayton@veonix.com

[JohnReppy]

The Word8.toLargeInt function is defined as the composition word64 to large int function with the word8 to word64 conversion. Based on the fact that the actual number reported each time one tries the example changes, I suspect that there is a representation inconsistency between the what is being produced by the word8 to word64 promotion and what is expected by the word64 to large int conversion. I think that the first is producing a pointer to a pair of 32-bit words, while the latter expects a flattened pair.

[JohnReppy]

After further investigation, I believe that I've isolated the cause of the bug. As mentioned above, the Word8.toLargeInt function is implemented as the composition of two other conversions. In the CPS IR, this composition is represented as code like the following:

      copy_8_64(v7) -> v16[I64]
      copy_64_inf(v16,v21) -> v13[PV]

In this code, v21 is the copy64Inf function from the core. After contraction, we have the following CPS code:

      copy_8_inf(v7,v21) -> v13[PV]

The problem is that the copy64Inf function is not correct for converting 8-bit values to IntInf.int values, but it is what will be used to implement the conversion.

At minimum, we should disable contraction of conversion compositions of the form ity --> i64 ; i64 --> inf, since the conversion function that we have in hand will be incorrect. (Note this restriction only applies to 32-bit platforms). The second issue is how to fix the Word8.toLargeInt conversion. For that part, I see two possible solutions:

1. change the definition to the conversion composition w8 --> i31 ; i31 --> inf
2. add additional primops for directly converting w8 --> inf
   I think that I will probably try the first choice, since it is easier.

[JohnReppy]

Fixed for 110.99.5.