[Git][ghc/ghc][wip/T22010] Update documentation accounting for 64 bit uniques

[Jaro Reinders (@Noughtmare)]

Jaro Reinders pushed to branch wip/T22010 at Glasgow Haskell Compiler / GHC


Commits:
2dfe61bd by Jaro Reinders at 2023-06-23T11:19:50+02:00
Update documentation accounting for 64 bit uniques

- - - - -


2 changed files:

- compiler/GHC/Types/Unique.hs
- compiler/GHC/Types/Unique/Supply.hs


Changes:

=====================================
compiler/GHC/Types/Unique.hs
=====================================
@@ -72,9 +72,9 @@ import Language.Haskell.Syntax.Module.Name
 
 Note [Uniques and masks]
 ~~~~~~~~~~~~~~~~~~~~~~~~
-A `Unique` in GHC is a Word-sized value composed of two pieces:
+A `Unique` in GHC is a 64 bit value composed of two pieces:
 * A "mask", of width `UNIQUE_TAG_BITS`, in the high order bits
-* A number, of width `uNIQUE_BITS`, which fills up the remainder of the Word
+* A number, of width `uNIQUE_BITS`, which fills up the remainder of the Word64
 
 The mask is typically an ASCII character.  It is typically used to make it easier
 to distinguish uniques constructed by different parts of the compiler.
@@ -82,7 +82,7 @@ There is a (potentially incomplete) list of unique masks used given in
 GHC.Builtin.Uniques. See Note [Uniques for wired-in prelude things and known masks]
 
 `mkUnique` constructs a `Unique` from its pieces
-  mkUnique :: Char -> Int -> Unique
+  mkUnique :: Char -> Word64 -> Unique
 
 -}
 
@@ -269,7 +269,7 @@ The alternatives are:
 
   1) Use UniqFM or UniqDFM, see Note [Deterministic UniqFM] to decide which
   2) Create a newtype wrapper based on Unique ordering where nondeterminism
-     is controlled. See Module.ModuleEnv
+     is controlled. See GHC.Unit.Module.Env.ModuleEnv
   3) Change the algorithm to use nonDetCmpUnique and document why it's still
      deterministic
   4) Use TrieMap as done in GHC.Cmm.CommonBlockElim.groupByLabel
@@ -313,13 +313,12 @@ instance Show Unique where
 ************************************************************************
 
 A character-stingy way to read/write numbers (notably Uniques).
-The ``62-its'' are \tr{[0-9a-zA-Z]}.  We don't handle negative Ints.
+The ``62-its'' are \tr{[0-9a-zA-Z]}.
 Code stolen from Lennart.
 -}
 
 w64ToBase62 :: Word64 -> String
-w64ToBase62 n_
-  = assert (n_ >= 0) $ go n_ ""
+w64ToBase62 n_ = go n_ ""
   where
     go n cs | n < 62
             = let !c = chooseChar62 (fromIntegral n) in c : cs


=====================================
compiler/GHC/Types/Unique/Supply.hs
=====================================
@@ -69,17 +69,17 @@ import GHC.Exts( wordToWord64# )
 The basic idea (due to Lennart Augustsson) is that a UniqSupply is
 lazily-evaluated infinite tree.
 
-* At each MkSplitUniqSupply node is a unique Int, and two
+* At each MkSplitUniqSupply node is a unique Word64, and two
   sub-trees (see data UniqSupply)
 
 * takeUniqFromSupply :: UniqSupply -> (Unique, UniqSupply)
-  returns the unique Int and one of the sub-trees
+  returns the unique Word64 and one of the sub-trees
 
 * splitUniqSupply :: UniqSupply -> (UniqSupply, UniqSupply)
   returns the two sub-trees
 
 * When you poke on one of the thunks, it does a foreign call
-  to get a fresh Int from a thread-safe counter, and returns
+  to get a fresh Word64 from a thread-safe counter, and returns
   a fresh MkSplitUniqSupply node.  This has to be as efficient
   as possible: it should allocate only
      * The fresh node
@@ -109,7 +109,7 @@ and thread it through the code, while in GHC.Core.Opt.Simplify.Monad  we use the
 and `uniqFromMask` in getUniqueM.
 
 Ultimately all these boil down to each new unique consisting of the mask and the result from
-a call to `genSym`. The later producing a distinct number for each invocation ensuring
+a call to `genSym`. The latter producing a distinct number for each invocation ensuring
 uniques are distinct.
 
 Note [Optimising the unique supply]



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/2dfe61bd7dacfe302c68193512c49c1f22a1d500

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/2dfe61bd7dacfe302c68193512c49c1f22a1d500
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230623/fd438788/attachment-0001.html>