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

[GHC]

#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