[Git][ghc/ghc][wip/fromasclist] 3 commits: compiler: Always load GHC.Data.FastString optimised into GHCi

[Cheng Shao (@TerrorJack)]

Cheng Shao pushed to branch wip/fromasclist at Glasgow Haskell Compiler / GHC


Commits:
662645f0 by Matthew Pickering at 2025-02-03T11:44:41-05:00
compiler: Always load GHC.Data.FastString optimised into GHCi

The FastString table is shared between the boot compiler and interpreted
compiler. Therefore it's very important the representation of
`FastString` matches in both cases. Otherwise, the interpreter will read
a FastString from the shared variable but place the fields in the wrong
place which leads to segfaults.

Ideally this state would not be shared, but for now we can always
compile both with `-O2` and this leads to a working interpreter.

- - - - -
05e5785a by Peter Trommler at 2025-02-03T11:45:17-05:00
RTS: Fix compile on powerpc64 ELF v1

Cabal does not know about the different ABIs for powerpc64 and compiles
StgCRunAsm.S unconditionally. The old make-based build system excluded
this file from the build and it was OK to signal an error when it was
compiled accidentally.

With this patch we compile StgCRunAsm.S to an empty file, which fixes
the build.

Fixes #25700

- - - - -
9a1ee181 by Cheng Shao at 2025-02-03T20:09:16+00:00
compiler: use fromAscList when applicable

This patch uses fromAscList (with O(n) complexity) instead of fromList
(with O(nlogn) complexity) in certain Binary instances. It's safe to
do so since the corresponding serialization logic is based on toList
(same as toAscList).

- - - - -


3 changed files:

- compiler/GHC/Data/FastString.hs
- compiler/GHC/Utils/Binary.hs
- rts/StgCRunAsm.S


Changes:

=====================================
compiler/GHC/Data/FastString.hs
=====================================
@@ -2,10 +2,19 @@
 {-# LANGUAGE MagicHash #-}
 {-# LANGUAGE UnboxedTuples #-}
 {-# LANGUAGE UnliftedFFITypes #-}
+{-# LANGUAGE CPP #-}
 
 {-# OPTIONS_GHC -O2 -funbox-strict-fields #-}
+#if MIN_VERSION_GLASGOW_HASKELL(9,8,0,0)
+{-# OPTIONS_GHC -fno-unoptimized-core-for-interpreter #-}
+#endif
 -- We always optimise this, otherwise performance of a non-optimised
 -- compiler is severely affected
+--
+-- Also important, if you load this module into GHCi then the data representation of
+-- FastString has to match that of the host compiler due to the shared FastString
+-- table. Otherwise you will get segfaults when the table is consulted and the fields
+-- from the FastString are in an incorrect order.
 
 -- |
 -- There are two principal string types used internally by GHC:


=====================================
compiler/GHC/Utils/Binary.hs
=====================================
@@ -940,8 +940,8 @@ instance Binary a => Binary [a] where
 -- | This instance doesn't rely on the determinism of the keys' 'Ord' instance,
 -- so it works e.g. for 'Name's too.
 instance (Binary a, Ord a) => Binary (Set a) where
-  put_ bh s = put_ bh (Set.toList s)
-  get bh = Set.fromList <$> get bh
+  put_ bh s = put_ bh (Set.toAscList s)
+  get bh = Set.fromAscList <$> get bh
 
 instance Binary a => Binary (NonEmpty a) where
     put_ bh = put_ bh . NonEmpty.toList
@@ -2086,5 +2086,5 @@ source location as part of a larger structure.
 --------------------------------------------------------------------------------
 
 instance (Binary v) => Binary (IntMap v) where
-  put_ bh m = put_ bh (IntMap.toList m)
-  get bh = IntMap.fromList <$> get bh
+  put_ bh m = put_ bh (IntMap.toAscList m)
+  get bh = IntMap.fromAscList <$> get bh


=====================================
rts/StgCRunAsm.S
=====================================
@@ -69,7 +69,7 @@ StgReturn:
 
 	.section	.note.GNU-stack,"", at progbits
 # else // Not ELF v2
-# error Only ELF v2 supported.
+       // ELF v1 is in StgCrun.c
 # endif
 
 #elif defined(powerpc_HOST_ARCH)



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/72151119bac6b3dd1621be5eac83ba6a3fa88c14...9a1ee1817c7bd4de15140ee0baac6007c7a4d1d0

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/72151119bac6b3dd1621be5eac83ba6a3fa88c14...9a1ee1817c7bd4de15140ee0baac6007c7a4d1d0
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/20250203/4062acfe/attachment-0001.html>