primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32

Was support for WORD_SIZE_IN_BITS < 32 dropped? According to this GHC commit, it appears that that support was dropped about seven years ago. Also, find -type f | xargs -n 5 egrep 'WORD_SIZE_IN_BITS\s*<\s*32' only finds mention of it in primops.txt.pp.

If support for that was dropped, the current version of compiler/prelude/primops.txt.pp has dead code and misleading documentation (that's apparently propagated to GHC.Prim documentation) that might cause programmers to expend unnecessary effort supporting WORD_SIZE_IN_BITS < 32 in their own code.

The following documentation describes a situation that can no longer happen and continues on incorrectly past these two paragraphs:

Haskell98 specifies that signed integers (type Int must contain at least 30 bits. GHC always implements Int using the primitive type Int#, whose size equals the MachDeps.h constant WORD_SIZE_IN_BITS.

This is normally set based on the config.h parameter SIZEOF_HSWORD, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, but 30 or 31-bit code can be exported as an external core file for use in other back ends.

The following is dead code. Further, INT32 and WORD32 throughout the document should be replaced with Int# and Word#:

#if WORD_SIZE_IN_BITS < 32
#define INT32 Int32#
#define WORD32 Word32#
#else
#define INT32 Int#
#define WORD32 Word#
#endif

Also, all code inclusively between #if WORD_SIZE_IN_BITS < 32 lines and their matching #endifs can be eliminated.

---

On the other hand, if WORD_SIZE_IN_BITS < 32 is still supported, there are a lot of cases wherein a 64-bit version of an instruction uses INT64 or WORD64 in its type signature, but the 32-bit version uses Int# or Word#, which robs programmers of the ability to use speedy hardware instructions on full untagged Int32#s or Word32#s. Also, the Double# decoder to two Word#s for the mantissa assumes that the Word#s can hold a full 32 bits according to its documentation. There are some other problems that I've forgotten as well.

Trac metadata

Trac field	Value
Version	8.4.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	tibbe
Operating system
Architecture