GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:09:37Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2234Profiled binaries create empty files2019-07-07T19:09:37ZguestProfiled binaries create empty files```
gwern@localhost:1891~>ghc --version [ 1:20PM]
The Glorious Glasgow Haskell Compilation System, version 6.8.2
```
I recently happened to...```
gwern@localhost:1891~>ghc --version [ 1:20PM]
The Glorious Glasgow Haskell Compilation System, version 6.8.2
```
I recently happened to go through the effort to build a copy of Darcs with profiling enabled (to profile, obviously), and while the profiling runs were quite as helpful as I could've wished, I've since noticed something very annoying:
```
gwern@localhost:1922~>~/bin/bin/darcs whatsnew [ 1:35PM]
No changes!
gwern@localhost:1923~>cat darcs.prof [ 1:36PM]
gwern@localhost:1924~>ls [ 1:36PM]
bin/ _darcs/ darcs.prof hacryptopp/ hiersort/ hope/ idris/ ivor/ par-gc-ismm08.pdf pics2/ torrent/
```
Note the complete lack of any +RTS-RTS flags; nevertheless, an annoying empty file has been created to clutter up my home directory. And deleting it is pointless since it'll just get created. Even worse, this stupid file will appear anywhere I use the profiled darcs (at last count, slocate knew of at least 12 such darcs.prof). And since my system is set up for profiling, it'll only get worse as more and more binaries get built for profiling.
I understand from Igloo there's some vague user-friendliness rationale behind GHC's littering, but I'm skeptical that this is really the best way to go about matters.
--
gwern6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1779unknown symbol `hs_hpc_module'2019-07-07T19:11:46Zguestunknown symbol `hs_hpc_module'During a :load command I got:
\<interactive\>: /home/foo/Bar/Baz.o: unknown symbol \`hs_hpc_module'
No test case available
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ...During a :load command I got:
\<interactive\>: /home/foo/Bar/Baz.o: unknown symbol \`hs_hpc_module'
No test case available
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unknown symbol `hs_hpc_module'","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.9","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"During a :load command I got:\r\n<interactive>: /home/foo/Bar/Baz.o: unknown symbol `hs_hpc_module'\r\n\r\nNo test case available","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1759HPC interaction with -Wall leading to spurious pattern match warnings2019-07-07T19:11:51ZguestHPC interaction with -Wall leading to spurious pattern match warningsWithout -fhpc, the following program passes the pattern match checker:
```
f :: String -> Int
f x | null x = 1
| otherwise = 2
main :: IO ()
main = print $ f []
```
However, with -fhpc on, we get the spurious warning:
```
...Without -fhpc, the following program passes the pattern match checker:
```
f :: String -> Int
f x | null x = 1
| otherwise = 2
main :: IO ()
main = print $ f []
```
However, with -fhpc on, we get the spurious warning:
```
A.hs:3:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `f': Patterns not matched: _
```
Causing libraries using -Werror to fail to build when using -fhpc.
}}}
-- Don
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.8 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dons@galois.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"HPC interaction with -Wall leading to spurious pattern match warnings","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8","keywords":["HPC"],"differentials":[],"test_case":"","architecture":"Unknown","cc":["dons@galois.com"],"type":"Bug","description":"Without -fhpc, the following program passes the pattern match checker:\r\n\r\n{{{\r\nf :: String -> Int\r\nf x | null x = 1\r\n | otherwise = 2\r\n\r\n\r\nmain :: IO ()\r\nmain = print $ f []\r\n}}}\r\n\r\nHowever, with -fhpc on, we get the spurious warning:\r\n\r\n{{{\r\n A.hs:3:0:\r\n Warning: Pattern match(es) are non-exhaustive\r\n In the definition of `f': Patterns not matched: _\r\n}}}\r\n\r\nCausing libraries using -Werror to fail to build when using -fhpc.\r\n}}}\r\n\r\n-- Don ","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1755Template Haskell quoting bug2019-07-07T19:11:52ZguestTemplate Haskell quoting bugQuoting local variable in a certain situation make GHC panic.
This OK:
```
foo = "foo"
expFoo :: Q Exp
expFoo = return (VarE 'foo)
```
But this will panic when you use $(expFoo) in another module:
```
expFoo :: Q Exp
expFoo = let fo...Quoting local variable in a certain situation make GHC panic.
This OK:
```
foo = "foo"
expFoo :: Q Exp
expFoo = return (VarE 'foo)
```
But this will panic when you use $(expFoo) in another module:
```
expFoo :: Q Exp
expFoo = let foo = "foo" in return (VarE 'foo)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell quoting bug","status":"New","operating_system":"Unknown","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Quoting local variable in a certain situation make GHC panic.\r\n\r\nThis OK:\r\n{{{\r\nfoo = \"foo\"\r\n\r\nexpFoo :: Q Exp\r\nexpFoo = return (VarE 'foo)\r\n}}}\r\n\r\nBut this will panic when you use $(expFoo) in another module:\r\n{{{\r\nexpFoo :: Q Exp\r\nexpFoo = let foo = \"foo\" in return (VarE 'foo)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1596ghc-pkg --define-name is undocumented2019-07-07T19:12:42Zeivuokkoghc-pkg --define-name is undocumentedIn ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output.
Is it meant to be stable interface?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...In ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output.
Is it meant to be stable interface?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg --define-name is undocumented","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"In ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output.\r\n\r\nIs it meant to be stable interface?","type_of_failure":"OtherFailure","blocking":[]} -->6.8.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1561No tabs in :t output2019-07-07T19:12:55Ziampure@gmail.comNo tabs in :t outputI'd like that :t doesn't generate output containing tab characters.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 ...I'd like that :t doesn't generate output containing tab characters.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"No tabs in :t output","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I'd like that :t doesn't generate output containing tab characters.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/998Tab-completion of filenames does not work in GHCi 6.62019-07-07T19:15:56Zdm.maillists@gmail.comTab-completion of filenames does not work in GHCi 6.6Trying to tab-complete filenames, for example when doing a :load, does not work in GHCi 6.6. It did work in GHCi 6.4.2.
Scenario:
```
$> ls
Baz Foo
$> ls Foo/
Bar.hs
$> ghci
Prelude> :l F<<press tab>>
Prelude> :l Foo/<press tab twice>>...Trying to tab-complete filenames, for example when doing a :load, does not work in GHCi 6.6. It did work in GHCi 6.4.2.
Scenario:
```
$> ls
Baz Foo
$> ls Foo/
Bar.hs
$> ghci
Prelude> :l F<<press tab>>
Prelude> :l Foo/<press tab twice>>
Baz/ Foo/
```
Rather than listing options of Baz and Foo it should have completed to Foo/Bar.hs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Tab-completion of filenames does not work in GHCi 6.6","status":"New","operating_system":"Linux","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Trying to tab-complete filenames, for example when doing a :load, does not work in GHCi 6.6. It did work in GHCi 6.4.2.\r\n\r\nScenario:\r\n\r\n{{{\r\n$> ls\r\nBaz Foo\r\n$> ls Foo/\r\nBar.hs\r\n$> ghci\r\nPrelude> :l F<<press tab>>\r\nPrelude> :l Foo/<press tab twice>>\r\nBaz/ Foo/\r\n}}}\r\n\r\nRather than listing options of Baz and Foo it should have completed to Foo/Bar.hs.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/414GHC does not eforce that Main exports main2020-03-22T17:02:46ZSimon Peyton JonesGHC does not eforce that Main exports main```
The Haskell 98 report says "A Haskell program is a
collection of
modules, one of which, by convention, must be called
Main and must
export the value main." However, the program below
builds and executes
fine.
module Main() -- sho...```
The Haskell 98 report says "A Haskell program is a
collection of
modules, one of which, by convention, must be called
Main and must
export the value main." However, the program below
builds and executes
fine.
module Main() -- should be "module Main" or "module
Main(main)"
where
main = putStrLn "Hello, World"
$ runghc Main.hs
Hello, World
Originally reported by Brian Smith
[brianlsmith@gmail.com]
```6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/249-caf-all bugs2019-07-07T19:18:50ZSimon Marlow-caf-all bugs```
P.C.Callaghan [p.c.callaghan@durham.ac.uk] submitted
this bug:
I'm trying to use the -caf-all flag with ghc-6.02, in
conjunction with -O
(which means going via C...)
But in a few modules of a large program, the .hc files
contain d...```
P.C.Callaghan [p.c.callaghan@durham.ac.uk] submitted
this bug:
I'm trying to use the -caf-all flag with ghc-6.02, in
conjunction with -O
(which means going via C...)
But in a few modules of a large program, the .hc files
contain duplicate
definitions of "MODsat_CAF_cc_ccs" (where MOD = a
particular module)
I can't see an obvious pattern to the number of
duplications. All the
affected modules use MPCs heavily. It doesn't look like
the duplications
are 1-1 with the instance decls. It only happens on a
few modules out
of many which also use classes heavily.
NB I hand-patched the .hc files by hand, and in the
results, not much of
the dictionary/caf info showed up! Should -auto-dicts work?
```6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/23534`-fprof-late` and `-fprof-auto` should likely be exclusive to each other.2023-09-07T09:34:51ZAndreas Klebinger`-fprof-late` and `-fprof-auto` should likely be exclusive to each other.When I first implemented -fprof-late I envisioned that people might have niche use cases where the existing profiling annotation methods and `fprof-late` would be useful.
I still think that's the case for some of these like `-fprof-call...When I first implemented -fprof-late I envisioned that people might have niche use cases where the existing profiling annotation methods and `fprof-late` would be useful.
I still think that's the case for some of these like `-fprof-callers` or `-fprof-auto-exported`. But for others it's likely to cause more confusion than good.
In this ticket: https://github.com/well-typed/optics/issues/469
People were repeatedly applying both `-fprof-auto` implicitly through cabal and `-fprof-late` explicitly. Resulting in *more* cost centres and overhead than expected.
While this is technically just a user error. I think it would be reasonable to make `-fprof-auto` either exclusive to `-fprof-late` or warn if both flags are used at the same time.9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/23522Error message for deriving type synonym is better and different with standalo...2023-07-03T09:02:56ZGregory GerasevError message for deriving type synonym is better and different with standalone derivingUsing standalone deriving
```
type My x = (Show x, Read x)
data Test = Test
deriving instance My Test
```
Error is:
```
<interactive>:19:25: error: [GHC-53946]
• Illegal instance for a type synonym
A class instance must be f...Using standalone deriving
```
type My x = (Show x, Read x)
data Test = Test
deriving instance My Test
```
Error is:
```
<interactive>:19:25: error: [GHC-53946]
• Illegal instance for a type synonym
A class instance must be for a class
• In the stand-alone deriving instance for ‘My Test’
```
But with inline deriving `data Test = Test deriving (My)` I am getting:
``
<interactive>:16:28: error: [GHC-11913]
• Illegal deriving item ‘My’
• In the data declaration for ‘Test’
``
All same with explicit `stock` strategy.
By the way: why type synonyms deriving is prohibited at all? Cannot GHC just try to expand it to regular constraints by rewriting type family?
* GHC version used: 9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/23364Add C compiler response file support detection logic2024-02-14T03:25:16ZCheng ShaoAdd C compiler response file support detection logicCurrently, when the GHC driver invokes a C compiler for compiling/linking, it assumes the compiler support response files unconditionally. However, there are rare cases that response files aren't supported by the C compiler driver (e.g. ...Currently, when the GHC driver invokes a C compiler for compiling/linking, it assumes the compiler support response files unconditionally. However, there are rare cases that response files aren't supported by the C compiler driver (e.g. https://github.com/AFLplusplus/AFLplusplus/issues/1730), so these cases should be taken into account. The GHC configure scripts should detect if the C compiler supports response files, that should get into `settings` which is later used by the GHC driver.https://gitlab.haskell.org/ghc/ghc/-/issues/22918mblock_map on 32-bit targets should be a compact bitset2024-02-14T03:09:46ZCheng Shaomblock_map on 32-bit targets should be a compact bitsetCurrently, on 32-bit targets, `mblock_map` is defined as a `StgWord8` array, with each byte representing a boolean for the corresponding mblock. This is easy to implement but wastes a lot of space. It should be possible to use a compact ...Currently, on 32-bit targets, `mblock_map` is defined as a `StgWord8` array, with each byte representing a boolean for the corresponding mblock. This is easy to implement but wastes a lot of space. It should be possible to use a compact bitset (implemented by `StgWord64` array) to represent `mblock_map`, with the following pros:
- No waste in space. This can be significant when we want to fine tune the mblock size for certain targets
- `getFirstMBlock` and `getNextMBlock` can get a nice speedup, a single memory load with a `ctz` instruction can check 64 mblock map entries at once.
Potential cons:
- `HEAP_ALLOCED()` takes more instructions since some bitwise operations are needed to calculate the correct index, and also to mask irrelevant bits. And it's a hot path in the RTS codebase.
Should we change `mblock_map` implementation? Opening a tracking ticket here and waiting for discussion with other folks familiar with RTS.https://gitlab.haskell.org/ghc/ghc/-/issues/22881Support -falignment-sanitisation in the wasm NCG2024-02-14T03:07:34ZCheng ShaoSupport -falignment-sanitisation in the wasm NCGCurrently, the wasm NCG doesn't support compiling with `-falignment-sanitisation`. It's not used by normal users, but may come in handy when debugging, plus it seems rather easy to implement anyway.Currently, the wasm NCG doesn't support compiling with `-falignment-sanitisation`. It's not used by normal users, but may come in handy when debugging, plus it seems rather easy to implement anyway.https://gitlab.haskell.org/ghc/ghc/-/issues/22879The LLVM codegen doesn't support the wasm target2024-02-14T03:06:24ZCheng ShaoThe LLVM codegen doesn't support the wasm targetRight now, the LLVM codegen doesn't support the wasm target yet, it would fail with:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230201:
Failed to lookup LLVM data layout
Target: wasm32-u...Right now, the LLVM codegen doesn't support the wasm target yet, it would fail with:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230201:
Failed to lookup LLVM data layout
Target: wasm32-unknown-wasi
Available targets:
```
Thus this tracking ticket. Marking this as a low-priority feature request instead of a bug at the moment. It'll take some time to look into the LLVM codegen logic and figure out how to teach the wasm NCG's calling convention to it.https://gitlab.haskell.org/ghc/ghc/-/issues/22831Support building wasm backend using emscripten2024-02-14T03:04:59ZCheng ShaoSupport building wasm backend using emscriptenCurrently, our wasm backend only works if the target toolchain is `wasi-sdk`. Using `emscripten` as the target toolchain requires some extra patches, and it'll fail at link-time with certain unresolved symbol warnings, likely caused by s...Currently, our wasm backend only works if the target toolchain is `wasi-sdk`. Using `emscripten` as the target toolchain requires some extra patches, and it'll fail at link-time with certain unresolved symbol warnings, likely caused by some incoherent feature macros across the tree (e.g. asserting that certain functionality like POSIX signal doesn't exist on `wasm32_HOST_ARCH`, but also using `HAVE_SIGNAL_H`, when `emscripten` sysroot does provide it).
The main reason for adding `emscripten` support is for better sanitizer support. According to https://emscripten.org/docs/debugging/Sanitizers.html, `emscripten` supports UBSAN and ASAN, both may be useful when debugging the wasm backend.https://gitlab.haskell.org/ghc/ghc/-/issues/22628Build fully_static linux bindists for the wasm backend2023-01-16T17:26:11ZCheng ShaoBuild fully_static linux bindists for the wasm backendI've just managed to build `fully_static` x86_64-linux bindists for wasm backend and wasi-sdk with alpine, and confirmed they work out of the box across a large number of distros (including NixOS, without needing to patchelf). Compared t...I've just managed to build `fully_static` x86_64-linux bindists for wasm backend and wasi-sdk with alpine, and confirmed they work out of the box across a large number of distros (including NixOS, without needing to patchelf). Compared to the current ubuntu-based build, it seems to me that this is a better way of redistributing binary artifacts in https://gitlab.haskell.org/ghc/ghc-wasm-meta.https://gitlab.haskell.org/ghc/ghc/-/issues/22619Avoid calling memcpy/memset for MO_Memcpy/MO_Memset in the wasm backend2024-02-14T03:03:12ZCheng ShaoAvoid calling memcpy/memset for MO_Memcpy/MO_Memset in the wasm backendCurrently, the wasm backend always lowers a `MO_Memcpy`/`MO_Memset` instruction to a ccall to `memcpy`/`memset`. The `-fmax-inline-memcpy-insns=⟨n⟩`/`-fmax-inline-memset-insns=⟨n⟩` GHC flags are ignored completely.
We can do something s...Currently, the wasm backend always lowers a `MO_Memcpy`/`MO_Memset` instruction to a ccall to `memcpy`/`memset`. The `-fmax-inline-memcpy-insns=⟨n⟩`/`-fmax-inline-memset-insns=⟨n⟩` GHC flags are ignored completely.
We can do something similar to the X86 NCG though: check these flags, and unroll small `MO_Memcpy`/`MO_Memset` instructions to inplace memory opcodes, avoiding the need for a ccall. When the size exceeds the threshold, we can emit a single `memory.copy`/`memory.fill` opcode and avoid the ccall anyway, since we already rely on the wasm bulk-memory extension.
Implementation is straightforward. The tricky part is coming up with an appropriate threshold value for wasm. `memory.copy`/`memory.fill` may be slower for small sizes, due to implementation detail of V8 and other runtimes, but we don't want to come up with an arbitrary number here. This issue should be revisited only after we have the infra to run benchmark suites like `nofib`.https://gitlab.haskell.org/ghc/ghc/-/issues/22614Use 64-bit GMP limbs on wasm322024-02-14T02:59:45ZCheng ShaoUse 64-bit GMP limbs on wasm32This is a rather low priority feature request, filed since I noticed a fact in GMP configure system: it's possible to forcibly use 64-bit limbs on 32-bit host archs. Our `ghc-bignum` has the assumption that limb size must equals word siz...This is a rather low priority feature request, filed since I noticed a fact in GMP configure system: it's possible to forcibly use 64-bit limbs on 32-bit host archs. Our `ghc-bignum` has the assumption that limb size must equals word size, though I think it's possible to relax that restriction.
Using 64-bit GMP limbs likely improves performance on wasm32 when dealing with large `Integer`s, since wasm32 supports i64 arithmetic perfectly, and in general the same amount of computation can be achieved by less i64 instructions than their i32 equivalents.https://gitlab.haskell.org/ghc/ghc/-/issues/22494Excessive floating2022-11-29T08:34:23ZSimon Peyton JonesExcessive floatingConsider this program
```
foo = case error "wombat" of { True -> "fred"; False -> "bill" }
```
Currently, FloatOut will float that `(error "wombat")` to top level, thus
```
lvl = error "wombat"
foo = case lvl of { True -> "fred"; False -...Consider this program
```
foo = case error "wombat" of { True -> "fred"; False -> "bill" }
```
Currently, FloatOut will float that `(error "wombat")` to top level, thus
```
lvl = error "wombat"
foo = case lvl of { True -> "fred"; False -> "bill" }
```
But that's a stupid thing to do. Nothing is gained.
The culprit is this code in `GHC.Core.Opt.SetLevels`
```
-- See Note [Floating to the top]
saves_alloc = isTopLvl dest_lvl
&& floatConsts env
&& (not strict_ctxt || is_bot || exprIsHNF expr)
```
For `is_bot` expressions we *always* float. I think it should be `(is_bot && escapes_value_lam)`. The main reason for floating is to make the function smaller, and more likely to inline; that's irrelevant for thunks.
Not a big deal, but easy to fix. I tripped over it when seeing this code in the output of `SetLevels` for [this example program](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9314#note_463710)
```
let {
<exit_s1oS,F<0,0>>
<exit_s1oS,F<0,0>>
= case let {
<lvl_s1oQ,F<0,0>>
<lvl_s1oQ,F<0,0>>
= Data.Text.Internal.Fusion.Common.head_empty
@GHC.Types.Char
($dIP1_s1oi
`cast` (Sym (GHC.Classes.N:IP[0]
<"callStack">_N <GHC.Stack.Types.CallStack>_N)
:: GHC.Stack.Types.CallStack
~R# (?callStack::GHC.Stack.Types.CallStack))) } in
lvl_s1oQ
of <wild_00,<0,2>> {
} } in
```
Notice that `exit_s1oS` is going to top level, but (separately and uselessly) so is `lvl_s1oQ`.