Changes between Version 4 and Version 5 of Commentary/Compiler/NewCodeGenStupidity


Ignore:
Timestamp:
Mar 23, 2011 1:16:30 PM (3 years ago)
Author:
ezyang
Comment:

extra note about allocDynClosure

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGenStupidity

    v4 v5  
    33Presently compiling using the new code generator results in a fairly sizable performance hit, because the new code generator produces sub-optimal (and sometimes absolutely terrible code.) There are [http://darcs.haskell.org/ghc/compiler/cmm/cmm-notes a lot of ideas for how to make things better]; the idea for this wiki page is to document all of the stupid things the new code generator is doing, to later be correlated with specific refactorings and fixes that will hopefully eliminate classes of these stupid things. The hope here is to develop a sense for what the most endemic problems with the newly generated code is. 
    44 
    5 == Cosmetic issues == 
     5== Lots of temporary variables == 
    66 
    7 The new code generator tends to generate C-- in the following style (which should be optimized away by the backends but can increase "line-noise"): 
     7Lots of temporary variables (these can tickle other issues when the temporaries are long-lived, but otherwise would be optimized away). You can at least eliminate some of them by looking at the output of `-ddump-opt-cmm`, which utilizes some basic temporary inlining when used with the native backend `-fasm`, but this doesn't currently apply to the GCC or LLVM backends. 
    88 
    9  - Lots of temporary variables (these can tickle other issues when the temporaries are long-lived, but otherwise would be optimized away). You can at least eliminate some of them by looking at the output of `-ddump-opt-cmm`, which utilizes some basic temporary inlining when used with the native backend `-fasm`, but this doesn't currently apply to the GCC or LLVM backends. 
     9At least one major culprit for this is `allocDynClosure`, described in Note `Return a LocalReg`; this pins down the value of the `CmmExpr` to be something for one particular time, but for a vast majority of use-cases the expression is used immediately afterwards. Actually, this is mostly my patches fault, because the extra rewrite means that the inline pass is broken. 
    1010 
    1111== Rewriting stacks ==