#4941: SpecConstr generates functions that do not use their arguments
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:                         
        Type:  task              |       Status:  new                    
    Priority:  normal            |    Milestone:  _|_                    
   Component:  Compiler          |      Version:  7.0.1                  
    Keywords:                    |     Testcase:                         
   Blockedby:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Blocking:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------

Comment(by batterseapower):

 Replying to [comment:17 simonpj]:
 > FYI: compiling with `-ticky` is a fantastic way to nail exactly where
 allocation increases.

 I have just tried this without success. Ticky tells me that a function
 $wtrim is increasing allocs by 23%, but I have traced it through manually
 and I just can't see how that can be happening.

 (I infer that the -ticky output includes those allocations made within a
 let-no-escape in the allocation count of their caller).

 To me it looks like the optimised code is never worse and sometimes an
 improvement in # of allocations metric - and optimisation reduces the
 number of let-no-escapes to boot. So I'm really flummoxed as to why
 allocations increase. It doesn't seem to be just because closure sizes
 increase or something because ALLOC_HEAP_ctr rises. Perhaps it would be
 clearer if ticky either told me a breakdown of allocation by the type of
 thing being allocated or by the let binding from which it originated.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to