GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:28:26Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11810Filtering of cost-center profiler output no longer works2019-07-07T18:28:26ZBen GamariFiltering of cost-center profiler output no longer worksWith the following testcase,
```hs
import Control.Monad (replicateM)
main :: IO ()
main = do
let xs = replicate 10000000 $ 42
print $ length xs
print $ sum xs
```
Running like this,
```
ghc -prof -auto-all Hi.hs && ./Hi +...With the following testcase,
```hs
import Control.Monad (replicateM)
main :: IO ()
main = do
let xs = replicate 10000000 $ 42
print $ length xs
print $ sum xs
```
Running like this,
```
ghc -prof -auto-all Hi.hs && ./Hi +RTS -hy[] -hc
```
with 7.10.3 produces a useful profile with the output one would expect. 8.0.1-rc2, on the other hand produces empty samples.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Filtering of cost-center profiler output no longer works","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the following testcase,\r\n{{{#!hs\r\nimport Control.Monad (replicateM)\r\n\r\nmain :: IO ()\r\nmain = do\r\n let xs = replicate 10000000 $ 42\r\n print $ length xs\r\n print $ sum xs\r\n}}}\r\n\r\nRunning like this,\r\n{{{\r\nghc -prof -auto-all Hi.hs && ./Hi +RTS -hy[] -hc\r\n}}}\r\nwith 7.10.3 produces a useful profile with the output one would expect. 8.0.1-rc2, on the other hand produces empty samples.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11627Segmentation fault for space_leak_001 with profiling (-hc)2019-08-21T10:36:42ZThomas MiedemaSegmentation fault for space_leak_001 with profiling (-hc)`WAY=profasm` is omitted by default for this test, but the code looks like this:
Test.hs:
```hs
import Data.List
main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer)
```
```
$ ghc Test.hs -prof -O
$ ./Test +RTS -hc
Segme...`WAY=profasm` is omitted by default for this test, but the code looks like this:
Test.hs:
```hs
import Data.List
main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer)
```
```
$ ghc Test.hs -prof -O
$ ./Test +RTS -hc
Segmentation fault (core dumped)
```
Reproducible with at least 7.10.3 and HEAD, also without `-O`.8.0.1jmejmehttps://gitlab.haskell.org/ghc/ghc/-/issues/11489Segmentation fault when .prof file not writeable2019-07-07T18:30:12ZThomas MiedemaSegmentation fault when .prof file not writeableTo reproduce:
```
$ echo 'main = return ()' > Test.hs
$ touch Test.prof
$ chmod -w Test.prof
$ ghc -prof Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test +RTS -hr{} -hc
Can't open profiling r...To reproduce:
```
$ echo 'main = return ()' > Test.hs
$ touch Test.prof
$ chmod -w Test.prof
$ ghc -prof Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test +RTS -hr{} -hc
Can't open profiling report file Test.prof
Segmentation fault (core dumped)
```
The warning is ok (maybe it should be an error?), but it shouldn't segfault.
Running `./Test +RTS -hr` works fine.
http://downloads.haskell.org/\~ghc/master/users-guide/profiling.html\#rts-options-for-heap-profiling:
- `-hc`: Breaks down the graph by the cost-centre stack which produced the data.
- `-hr⟨cc⟩`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top.
Bug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002):
```
- you can now restrict a heap profile to certain retainer sets,
but still display by cost centre (or type, or closure or
whatever).
```
Because it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001):
```
// The following line was added by Sung; retainer/LDV profiling may need
// two output files, i.e., <program>.prof/hp.
if (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER)
RtsFlags.ProfFlags.doHeapProfile = 0;
```
Another relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6:
```
Author: simonmar <unknown>
Date: Wed Nov 28 15:42:26 2001 +0000
[project @ 2001-11-28 15:42:26 by simonmar]
Don't need the .prof file when LDV-profiling.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segmentation fault when .prof file not writeable","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To reproduce:\r\n{{{\r\n$ echo 'main = return ()' > Test.hs\r\n\r\n$ touch Test.prof\r\n\r\n$ chmod -w Test.prof\r\n\r\n$ ghc -prof Test.hs\r\n[1 of 1] Compiling Main ( Test.hs, Test.o )\r\nLinking Test ...\r\n\r\n$ ./Test +RTS -hr{} -hc\r\nCan't open profiling report file Test.prof\r\nSegmentation fault (core dumped)\r\n}}}\r\n\r\nThe warning is ok (maybe it should be an error?), but it shouldn't segfault.\r\n\r\nRunning `./Test +RTS -hr` works fine.\r\n\r\nhttp://downloads.haskell.org/~ghc/master/users-guide/profiling.html#rts-options-for-heap-profiling:\r\n* `-hc`: Breaks down the graph by the cost-centre stack which produced the data.\r\n* `-hr⟨cc⟩`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top.\r\n\r\nBug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002):\r\n{{{\r\n- you can now restrict a heap profile to certain retainer sets,\r\n but still display by cost centre (or type, or closure or\r\n whatever).\r\n}}}\r\n\r\nBecause it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001):\r\n{{{\r\n// The following line was added by Sung; retainer/LDV profiling may need\r\n// two output files, i.e., <program>.prof/hp.\r\nif (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER)\r\n RtsFlags.ProfFlags.doHeapProfile = 0;\r\n}}}\r\n\r\nAnother relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6:\r\n{{{\r\nAuthor: simonmar <unknown>\r\nDate: Wed Nov 28 15:42:26 2001 +0000\r\n\r\n [project @ 2001-11-28 15:42:26 by simonmar]\r\n Don't need the .prof file when LDV-profiling.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/10661Regression: hp2ps reports `integer unexpected` on new style package keys2019-07-07T18:34:46ZThomas MiedemaRegression: hp2ps reports `integer unexpected` on new style package keyshp2ps reports `integer unexpected` when run on a profile file created with HEAD. The profile file contains entries such as the following:
```
$ grep System.Random Test.hp
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw...hp2ps reports `integer unexpected` when run on a profile file created with HEAD. The profile file contains entries such as the following:
```
$ grep System.Random Test.hp
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen 24
```
To reproduce, first install random (there might be a simpler way, but this one is required to run `make TEST=concprog002 WAY=threaded2_hT`, which is failing at the moment):
```
$ cabal install random==1.1 --with-ghc=ghc-7.11.20150711 -v0
```
Note the package key for random starts with a number:
```
$ ghc-pkg --package-db=.ghc/x86_64-linux-7.11.20150711/package.conf.d/ describe random | grep key
key: 9Kgekc9yEaLHLNUuw6paWL
```
Then create a heap profile for the following program with `-hT`, and try to run `hp2ps` on it:
```
$ cat Test.hs
import System.Random
main = sequence $ replicate 1000 (randomIO :: IO Int)
$ ghc-7.11.20150711 Test.hs -rtsopts -fforce-recomp -v0
$ ./Test +RTS -hT -i0.001
$ hp2ps Test.hp
hp2ps: Test.hp, line 12: integer unexpected
```
Note that in the profile file the entries for libraries like `base`, `ghc-prim` and `integer-gmp` don't contain package keys (maybe the entries for random shouldn't either?):
```
base:Data.Dynamic.Dynamic 24
integer-gmp:GHC.Integer.Type.Jp# 16
ghc-prim:GHC.Types.: 24
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression: hp2ps reports `integer unexpected` on new style package keys","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"hp2ps reports `integer unexpected` when run on a profile file created with HEAD. The profile file contains entries such as the following:\r\n\r\n{{{\r\n$ grep System.Random Test.hp \r\n9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen\t24\r\n9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen\t24\r\n9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen\t24\r\n9Kgekc9yEaLHLNUuw6paWL:System.Random.StdGen\t24\r\n}}}\r\n\r\n\r\nTo reproduce, first install random (there might be a simpler way, but this one is required to run `make TEST=concprog002 WAY=threaded2_hT`, which is failing at the moment):\r\n\r\n{{{\r\n$ cabal install random==1.1 --with-ghc=ghc-7.11.20150711 -v0\r\n}}}\r\n\r\nNote the package key for random starts with a number:\r\n\r\n{{{\r\n$ ghc-pkg --package-db=.ghc/x86_64-linux-7.11.20150711/package.conf.d/ describe random | grep key\r\nkey: 9Kgekc9yEaLHLNUuw6paWL\r\n}}}\r\n\r\nThen create a heap profile for the following program with `-hT`, and try to run `hp2ps` on it:\r\n\r\n{{{\r\n$ cat Test.hs\r\nimport System.Random\r\nmain = sequence $ replicate 1000 (randomIO :: IO Int)\r\n\r\n$ ghc-7.11.20150711 Test.hs -rtsopts -fforce-recomp -v0\r\n\r\n$ ./Test +RTS -hT -i0.001\r\n\r\n$ hp2ps Test.hp\r\nhp2ps: Test.hp, line 12: integer unexpected\r\n}}}\r\n\r\nNote that in the profile file the entries for libraries like `base`, `ghc-prim` and `integer-gmp` don't contain package keys (maybe the entries for random shouldn't either?):\r\n{{{\r\n base:Data.Dynamic.Dynamic 24\r\n integer-gmp:GHC.Integer.Type.Jp# 16\r\n ghc-prim:GHC.Types.: 24\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10037Several profiling tests give different results optimised vs. unoptimised2021-06-08T19:30:58ZSimon MarlowSeveral profiling tests give different results optimised vs. unoptimisedMost of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket.
The following tests in `tests/profiling/should_run`...Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket.
The following tests in `tests/profiling/should_run` are affected:
```
scc001
T2552
ioprof
callstack001
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Several profiling tests give different results optimised vs. unoptimised","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket.\r\n\r\nThe following tests in `tests/profiling/should_run` are affected:\r\n\r\n{{{\r\nscc001\r\nT2552\r\nioprof\r\ncallstack001\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/7763Resource limits for Haskell2019-07-07T18:48:15ZEdward Z. YangResource limits for Haskell```
commit 1f5eb79cc278fd64ee3f1f4249ea3b7404f62ba1
Author: Edward Z. Yang <ezyang@mit.edu>
Date: Thu Mar 7 13:53:31 2013 -0800
Primops and runtime support for space resource limits.
This patch adds support for resource l...```
commit 1f5eb79cc278fd64ee3f1f4249ea3b7404f62ba1
Author: Edward Z. Yang <ezyang@mit.edu>
Date: Thu Mar 7 13:53:31 2013 -0800
Primops and runtime support for space resource limits.
This patch adds support for resource limits in Haskell, especially
for monitoring and triggering events when portions of Haskell code
exceed memory usage and/or allocation. The system is described in
more detail at.
http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits
This patch adds the following types:
CostCentre# - non-GCd pointer to CostCentre struct
CostCentreStack# - non-GCd pointer to CostCentreStack struct
Listener# - GC'd object for listening to pointer events
and the following primops:
ccToAddr
addrToCC
ccsToAddr
addrToCCS
newCC#
setCCSOf#
withCCS#
pushCC#
queryCCS#
listenCCS#
unlistenCCS#
These previously existing primops have had their types changed,
mainly for better type safety (replacing Addr# with CostCentreStack#)
getCCSOf#
getCurrentCCS#
We add the following new RTS options:
-hl equivalent to -hc but also keeps census information in-memory
for access and does not write out a *.hp file
-xf modified cost-centre stack semantics, where function entries
never modify the stack (so only CAFs and explicit set CCCS
affect cost-centres).
To utilize these new features, compile with -prof and run with +RTS -hl -xf
```
See also http://hackage.haskell.org/trac/ghc/wiki/Commentary/ResourceLimits
Probably the most dodgy parts of the patch is the primop code for `withCCS#`, and some of the refactoring of the heap profiler.8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7443Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile2019-07-07T18:49:42ZorenbenkikiGenerated C code under -prof -fprof-auto -fprof-cafs very slow to compileSome background: This is C code generated when I turned on profiling with -fprof-auto -fprof-cafs, on Haskell code that contains a large amount of injected TemplateHaskell code. GHC takes several minutes to compile this on its side; but ...Some background: This is C code generated when I turned on profiling with -fprof-auto -fprof-cafs, on Haskell code that contains a large amount of injected TemplateHaskell code. GHC takes several minutes to compile this on its side; but for some reason it emits the attached C code, which (if compiled with -O) takes "forever" to compile. At least, I killed it after consuming 3 hours of CPU and occupying 9GB of RAM.
I also opened a GCC bug for this; but a cursory look seems to indicate this C code is trying to build a linked list in memory, which it seems should be doable in a much more straightforward way. In fact since the list of CAFs will not change in run-time, it should be possible to initialize it in compile time as:
```
ENTRY entry_0[1] = { ..., link = NULL };
ENTRY entry_1[1] = { ..., link = entry_0 };
...
head = entry_n;
```
And this is before wondering why not use an array of entries instead of a linked list in the 1st place. That said, I am just guessing here, I have no understanding of what is really going on, other than the fact I was forced to add {-\# OPTIONS_GHC -optc -O0 \#-} to the offending file.
Attached is a tgz file containing the generated C code (plus a version which is post-CPP, so you can just try to compile it in various ways on systems without GHC installed).8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/7246Callstack depends on way (prof, profasm, profthreaded2019-07-07T18:50:42ZJoachim Breitnermail@joachim-breitner.deCallstack depends on way (prof, profasm, profthreadedConsider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:
```
=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]
cd . && '/home/jojo/doku...Consider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:
```
=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]
cd . && '/home/jojo/dokumente/Uni/info/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o callstack003 callstack003.hs -O -prof -auto-all -threaded -fprof-auto-calls -fno-full-laziness -fno-state-hack >callstack003.comp.stderr 2>&1
cd . && ./callstack003 +RTS -p -RTS </dev/null >callstack003.run.stdout 2>callstack003.run.stderr
Actual stdout output differs from expected:
--- ./callstack003.stdout 2012-09-17 11:27:02.607458948 +0200
+++ ./callstack003.run.stdout 2012-09-17 12:20:33.988109494 +0200
@@ -1,8 +1,8 @@
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:15-17)","Main.f (callstack003.hs:7:11-36)"]
-["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.doTwice (callstack003.hs:10:22-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
+["Main.CAF (<entire-module>)","Main.main (callstack003.hs:9:8-21)","Main.doTwice (callstack003.hs:10:15-24)","Main.f (callstack003.hs:7:11-36)"]
*** unexpected failure for callstack003(profthreaded)
```
Not sure if this really hurts anyone, and the behavior of the call stack WRT recursive calls is anyways not quite perfect yet (see #7240), this makes adding good test cases a bit difficult.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Callstack depends on way (prof, profasm, profthreaded","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the attached test case. The expected output is the that of the ```prof``` way, while for ```profasm``` and ```profthreaded```, I get this result:\r\n\r\n{{{\r\n=====> callstack003(profthreaded) 19 of 21 [0, 1, 0]\r\ncd . && '/home/jojo/dokumente/Uni/info/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o callstack003 callstack003.hs -O -prof -auto-all -threaded -fprof-auto-calls -fno-full-laziness -fno-state-hack >callstack003.comp.stderr 2>&1\r\ncd . && ./callstack003 +RTS -p -RTS </dev/null >callstack003.run.stdout 2>callstack003.run.stderr\r\nActual stdout output differs from expected:\r\n--- ./callstack003.stdout\t2012-09-17 11:27:02.607458948 +0200\r\n+++ ./callstack003.run.stdout\t2012-09-17 12:20:33.988109494 +0200\r\n@@ -1,8 +1,8 @@\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:15-17)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n-[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.doTwice (callstack003.hs:10:22-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n+[\"Main.CAF (<entire-module>)\",\"Main.main (callstack003.hs:9:8-21)\",\"Main.doTwice (callstack003.hs:10:15-24)\",\"Main.f (callstack003.hs:7:11-36)\"]\r\n*** unexpected failure for callstack003(profthreaded)\r\n}}}\r\n\r\nNot sure if this really hurts anyone, and the behavior of the call stack WRT recursive calls is anyways not quite perfect yet (see #7240), this makes adding good test cases a bit difficult.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/7240Stack trace truncated too much with indirect recursion2019-07-07T18:50:44ZJoachim Breitnermail@joachim-breitner.deStack trace truncated too much with indirect recursionThis is to write down the improvements suggestions for the stack trace that I had after the HIW talk. Consider:
```
$ cat truncstack.hs
import System.Environment
import Debug.Trace
runThisTwice x y = x y >> x y
main = getArgs >>= runT...This is to write down the improvements suggestions for the stack trace that I had after the HIW talk. Consider:
```
$ cat truncstack.hs
import System.Environment
import Debug.Trace
runThisTwice x y = x y >> x y
main = getArgs >>= runThisTwice go1 . head
go1 l = runThisTwice go2 l
go2 l = runThisTwice go l
go x = traceStack x (error "done")
$ ghc --make -prof -fprof-auto truncstack.hs && ./truncstack x
[1 of 1] Compiling Main ( truncstack.hs, truncstack.o )
Linking truncstack ...
x
Stack trace:
Main.go (truncstack.hs:8:1-34)
Main.runThisTwice (truncstack.hs:4:1-29)
Main.main (truncstack.hs:5:1-42)
Main.CAF (<entire-module>)
truncstack: done
```
Clearly. the programer would want go1 and go2 to be mentioned as well.
I think it would not be too hard to keep the stacktrace more complete and only truncate “real” recursion (i.e. repeating sublists in the stack), or even annotate them with the number of loops. Simon Marlow told me that one need to ensure that a change in the stack does not have unwanted effects on the profiling attributions.
I plan to look into this issue (unless someone shouts “no no don’t do that”).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Stack trace truncated too much with indirect recursion","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"nomeata"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is to write down the improvements suggestions for the stack trace that I had after the HIW talk. Consider:\r\n\r\n{{{\r\n$ cat truncstack.hs \r\nimport System.Environment\r\nimport Debug.Trace\r\n\r\nrunThisTwice x y = x y >> x y\r\nmain = getArgs >>= runThisTwice go1 . head\r\ngo1 l = runThisTwice go2 l\r\ngo2 l = runThisTwice go l\r\ngo x = traceStack x (error \"done\")\r\n$ ghc --make -prof -fprof-auto truncstack.hs && ./truncstack x\r\n[1 of 1] Compiling Main ( truncstack.hs, truncstack.o )\r\nLinking truncstack ...\r\nx\r\nStack trace:\r\n Main.go (truncstack.hs:8:1-34)\r\n Main.runThisTwice (truncstack.hs:4:1-29)\r\n Main.main (truncstack.hs:5:1-42)\r\n Main.CAF (<entire-module>)\r\ntruncstack: done\r\n}}}\r\n\r\nClearly. the programer would want go1 and go2 to be mentioned as well.\r\n\r\nI think it would not be too hard to keep the stacktrace more complete and only truncate “real” recursion (i.e. repeating sublists in the stack), or even annotate them with the number of loops. Simon Marlow told me that one need to ensure that a change in the stack does not have unwanted effects on the profiling attributions.\r\n\r\nI plan to look into this issue (unless someone shouts “no no don’t do that”).","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/7190GHC's -fprof-auto does not work with LINE pragmas2019-07-07T18:50:56ZtimthelionGHC's -fprof-auto does not work with LINE pragmasPlease note the difference between the two .prof files created. The "profnopragma" one contains a "main" and the "profpragma" one doesn't. I came across this problem profiling a much larger source. In that case, ghc failed to profile any...Please note the difference between the two .prof files created. The "profnopragma" one contains a "main" and the "profpragma" one doesn't. I came across this problem profiling a much larger source. In that case, ghc failed to profile anything within my source code at all!
```
[timothy@timothy haskell]$ cat profpragma.hs
f="hi"{-# LINE 1 "hi.hs" #-}
main :: IO (){-# LINE 2 "hi.hs" #-}
main = print f{-# LINE 3 "hi.hs" #-}
[timothy@timothy haskell]$ cat profnopragma.hs
f="hi"
main :: IO ()
main = print f
[timothy@timothy haskell]$ ghc profpragma.hs -prof -fprof-auto
[timothy@timothy haskell]$ ghc profnopragma.hs -prof -fprof-auto
[timothy@timothy haskell]$ ./profpragma +RTS -p
"hi"
[timothy@timothy haskell]$ ./profnopragma +RTS -p
"hi"
[timothy@timothy haskell]$ cat profpragma.prof
Sun Aug 26 20:30 2012 Time and Allocation Profiling Report (Final)
profpragma +RTS -p -RTS
total time = 0.00 secs (0 ticks @ 1000 us, 1 processor)
total alloc = 49,704 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
CAF GHC.IO.Encoding 0.0 5.6
CAF GHC.IO.Handle.FD 0.0 69.8
CAF GHC.Conc.Signal 0.0 1.4
CAF Main 0.0 21.7
individual inherited
COST CENTRE MODULE no. entries %time %alloc %time %alloc
MAIN MAIN 46 0 0.0 0.7 0.0 100.0
CAF Main 91 0 0.0 21.7 0.0 22.1
f Main 92 1 0.0 0.3 0.0 0.3
CAF GHC.Conc.Signal 87 0 0.0 1.4 0.0 1.4
CAF GHC.IO.Handle.FD 85 0 0.0 69.8 0.0 69.8
CAF GHC.IO.Encoding 80 0 0.0 5.6 0.0 5.6
CAF GHC.IO.Encoding.Iconv 66 0 0.0 0.5 0.0 0.5
[timothy@timothy haskell]$ cat profnopragma.prof
Sun Aug 26 20:30 2012 Time and Allocation Profiling Report (Final)
profnopragma +RTS -p -RTS
total time = 0.00 secs (0 ticks @ 1000 us, 1 processor)
total alloc = 49,704 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
CAF GHC.IO.Encoding 0.0 5.6
CAF GHC.IO.Handle.FD 0.0 69.8
CAF GHC.Conc.Signal 0.0 1.4
main Main 0.0 20.8
individual inherited
COST CENTRE MODULE no. entries %time %alloc %time %alloc
MAIN MAIN 46 0 0.0 0.7 0.0 100.0
CAF Main 91 0 0.0 0.9 0.0 22.1
f Main 93 1 0.0 0.3 0.0 0.3
main Main 92 1 0.0 20.8 0.0 20.8
CAF GHC.Conc.Signal 87 0 0.0 1.4 0.0 1.4
CAF GHC.IO.Handle.FD 85 0 0.0 69.8 0.0 69.8
CAF GHC.IO.Encoding 80 0 0.0 5.6 0.0 5.6
CAF GHC.IO.Encoding.Iconv 66 0 0.0 0.5 0.0 0.5
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC's -fprof-auto does not work with LINE pragmas","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Please note the difference between the two .prof files created. The \"profnopragma\" one contains a \"main\" and the \"profpragma\" one doesn't. I came across this problem profiling a much larger source. In that case, ghc failed to profile anything within my source code at all!\r\n\r\n{{{\r\n[timothy@timothy haskell]$ cat profpragma.hs\r\nf=\"hi\"{-# LINE 1 \"hi.hs\" #-}\r\nmain :: IO (){-# LINE 2 \"hi.hs\" #-}\r\nmain = print f{-# LINE 3 \"hi.hs\" #-}\r\n[timothy@timothy haskell]$ cat profnopragma.hs\r\nf=\"hi\"\r\nmain :: IO ()\r\nmain = print f\r\n[timothy@timothy haskell]$ ghc profpragma.hs -prof -fprof-auto\r\n[timothy@timothy haskell]$ ghc profnopragma.hs -prof -fprof-auto\r\n[timothy@timothy haskell]$ ./profpragma +RTS -p\r\n\"hi\"\r\n[timothy@timothy haskell]$ ./profnopragma +RTS -p\r\n\"hi\"\r\n[timothy@timothy haskell]$ cat profpragma.prof \r\n\tSun Aug 26 20:30 2012 Time and Allocation Profiling Report (Final)\r\n\r\n\t profpragma +RTS -p -RTS\r\n\r\n\ttotal time = 0.00 secs (0 ticks @ 1000 us, 1 processor)\r\n\ttotal alloc = 49,704 bytes (excludes profiling overheads)\r\n\r\nCOST CENTRE MODULE %time %alloc\r\n\r\nCAF GHC.IO.Encoding 0.0 5.6\r\nCAF GHC.IO.Handle.FD 0.0 69.8\r\nCAF GHC.Conc.Signal 0.0 1.4\r\nCAF Main 0.0 21.7\r\n\r\n\r\n individual inherited\r\nCOST CENTRE MODULE no. entries %time %alloc %time %alloc\r\n\r\nMAIN MAIN 46 0 0.0 0.7 0.0 100.0\r\n CAF Main 91 0 0.0 21.7 0.0 22.1\r\n f Main 92 1 0.0 0.3 0.0 0.3\r\n CAF GHC.Conc.Signal 87 0 0.0 1.4 0.0 1.4\r\n CAF GHC.IO.Handle.FD 85 0 0.0 69.8 0.0 69.8\r\n CAF GHC.IO.Encoding 80 0 0.0 5.6 0.0 5.6\r\n CAF GHC.IO.Encoding.Iconv 66 0 0.0 0.5 0.0 0.5\r\n[timothy@timothy haskell]$ cat profnopragma.prof \r\n\tSun Aug 26 20:30 2012 Time and Allocation Profiling Report (Final)\r\n\r\n\t profnopragma +RTS -p -RTS\r\n\r\n\ttotal time = 0.00 secs (0 ticks @ 1000 us, 1 processor)\r\n\ttotal alloc = 49,704 bytes (excludes profiling overheads)\r\n\r\nCOST CENTRE MODULE %time %alloc\r\n\r\nCAF GHC.IO.Encoding 0.0 5.6\r\nCAF GHC.IO.Handle.FD 0.0 69.8\r\nCAF GHC.Conc.Signal 0.0 1.4\r\nmain Main 0.0 20.8\r\n\r\n\r\n individual inherited\r\nCOST CENTRE MODULE no. entries %time %alloc %time %alloc\r\n\r\nMAIN MAIN 46 0 0.0 0.7 0.0 100.0\r\n CAF Main 91 0 0.0 0.9 0.0 22.1\r\n f Main 93 1 0.0 0.3 0.0 0.3\r\n main Main 92 1 0.0 20.8 0.0 20.8\r\n CAF GHC.Conc.Signal 87 0 0.0 1.4 0.0 1.4\r\n CAF GHC.IO.Handle.FD 85 0 0.0 69.8 0.0 69.8\r\n CAF GHC.IO.Encoding 80 0 0.0 5.6 0.0 5.6\r\n CAF GHC.IO.Encoding.Iconv 66 0 0.0 0.5 0.0 0.5\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/6113Profiling with -p not written if killed with SIGTERM2022-03-01T11:55:54ZVeinorProfiling with -p not written if killed with SIGTERMJust like it says in the title; -p profiling seems to only get written if the binary gets killed with a SIGINT, not QUIT or TERM. Haven't tested the others, but it seems reasonable that -p profiling data should always be written on exit....Just like it says in the title; -p profiling seems to only get written if the binary gets killed with a SIGINT, not QUIT or TERM. Haven't tested the others, but it seems reasonable that -p profiling data should always be written on exit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Profiling with -p not written if killed with SIGTERM","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just like it says in the title; -p profiling seems to only get written if the binary gets killed with a SIGINT, not QUIT or TERM. Haven't tested the others, but it seems reasonable that -p profiling data should always be written on exit.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/5641The -L flag should not exist2021-01-22T09:59:58Zlennart@augustsson.netThe -L flag should not existWhy does the -L flag exist? The .hp file should contain untruncated strings, and any truncation of the names should be done in hp2ps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------...Why does the -L flag exist? The .hp file should contain untruncated strings, and any truncation of the names should be done in hp2ps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The -L flag should not exist","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Why does the -L flag exist? The .hp file should contain untruncated strings, and any truncation of the names should be done in hp2ps.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4837Template Haskell does not work in a profiled compiler.2019-07-07T18:58:17ZbenlTemplate Haskell does not work in a profiled compiler.Template Haskell does not work if the compiler itself is built profiles. Because of this we cannot debug GHC compile time performance problems when compiling Data.Vector and DPH as they use Template Haskell. #4172 is related.
Trying to ...Template Haskell does not work if the compiler itself is built profiles. Because of this we cannot debug GHC compile time performance problems when compiling Data.Vector and DPH as they use Template Haskell. #4172 is related.
Trying to use Template Haskell in a profiled compiler currently triggers the assertion at `main/HscMain.hs:1245`
Supporting this would also mean that we can run GHCi with profiled code!8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1420Automatic heap profile intervals2020-12-07T13:41:49ZguestAutomatic heap profile intervalsWhen doing heap profiling it is sometimes hard to know what a good sampling interval is. Make it too small and it takes forever, make it too coarse and the resolution is bad.
In hbc the default setting was to automatically adjust the int...When doing heap profiling it is sometimes hard to know what a good sampling interval is. Make it too small and it takes forever, make it too coarse and the resolution is bad.
In hbc the default setting was to automatically adjust the interval. It starts out very small, but as samples accumulate it gets larger and larger. This is a nice compromise.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart.augustsson@credit-suisse.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Automatic heap profile intervals","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["lennart.augustsson@credit-suisse.com"],"type":"FeatureRequest","description":"When doing heap profiling it is sometimes hard to know what a good sampling interval is. Make it too small and it takes forever, make it too coarse and the resolution is bad.\r\nIn hbc the default setting was to automatically adjust the interval. It starts out very small, but as samples accumulate it gets larger and larger. This is a nice compromise.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/609Useful optimisation for set-cost-centre2019-07-07T19:18:35ZSimon Peyton JonesUseful optimisation for set-cost-centreIf you compile, for example, drvrun014 with -prof -auto-all, you'll see stuff like
```
(scc "c" (dataToTag#)) y
```
This generates bad code, because we end up eta-expaning dataToTag, which allocates an extra function closure.
We t...If you compile, for example, drvrun014 with -prof -auto-all, you'll see stuff like
```
(scc "c" (dataToTag#)) y
```
This generates bad code, because we end up eta-expaning dataToTag, which allocates an extra function closure.
We think that in general
```
(scc "c" e) y = scc "c" (e y)
```
to within a small constant factor. So maybe the simplifier, or `CorePrep`, or both, should do this transformation.8.0.1Simon MarlowSimon Marlow