Re: [GHC] #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile

#7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile ---------------------------------+------------------------------------------ Reporter: orenbenkiki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description:
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).
New description: 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). -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7443#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC