Changes between Version 20 and Version 21 of Commentary/Compiler/NewCodeGenStupidity


Ignore:
Timestamp:
Apr 16, 2011 7:31:43 PM (3 years ago)
Author:
ezyang
Comment:

add statuses

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGenStupidity

    v20 v21  
    55== Lots of temporary variables == 
    66 
    7 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. 
     7WONTFIX. 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. 
    88 
    99~~At 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.~~ Fixed in latest version of the pass; we don't quite manage to inline enough but there's only one extra temporary. 
     
    1313== Rewriting stacks == 
    1414 
    15 `3586.hs` emits the following code: 
     15FIXED. `3586.hs` emits the following code: 
    1616 
    1717{{{ 
     
    5959Since these areas on the stack are all old call areas, one way to fix this is to inline all of the memory references. However, this has certain undesirable properties for other code, so we need to be a little more clever. The key thing to notice is that these accesses are only used once per control flow path, in which case sinking the loads down and then inlining them should be OK (it will increase code size but not execution time.) However, the other difficulty is that the CmmOpt inliner, as it stands, won't inline things that look like this because although the variable is only used once in different branches, the same name is used, so it can't distinguish between the temporaries with mutually exclusive live ranges. Building a more clever inliner with Hoopl is also a bit tricky, because inlining is a forward analysis/transformation, but usage counting is a backwards analysis. 
    6060 
    61 This looks fixed with the patch from April 14, though there are still other problems with this file. 
     61This looks fixed with the patch from April 14. 
    6262 
    6363== Spilling Hp/Sp == 
    6464 
    65  
    66 `3586.hs` emits the following code: 
     65FIXED. `3586.hs` emits the following code: 
    6766 
    6867{{{ 
     
    9594~~We need to not spill across certain foreign calls, but for which calls this is OK for is unclear.~~ Variables stay live across all unsafe foreign calls (foreign calls in the middle), except for the obvious cases (the return registers), so no spilling should happen at all. The liveness analysis is too conservative. 
    9695 
    97 This is not fixed in the April 14 version of the patch... we still need to fix the liveness analysis? I thought I fixed that... that's because the transform did extra spilling for CmmUnsafeForeignCalls. Removed that code, and now it's fixed. Testing changes. 
     96This is not fixed in the April 14 version of the patch... we still need to fix the liveness analysis? I thought I fixed that... that's because the transform did extra spilling for CmmUnsafeForeignCalls. Removed that code, and now it's fixed. 
    9897 
    9998== Up and Down == 
    10099 
    101 A frequent pattern is the stack pointer being bumped up and then back down again, for no particular reason.  
     100FIXD. A frequent pattern is the stack pointer being bumped up and then back down again, for no particular reason.  
    102101 
    103102{{{ 
     
    111110== Sp is generally stupid == 
    112111 
    113 Here is an optimized C-- sample from `arr016.hs`. 
     112CONFIRMED. Here is an optimized C-- sample from `arr016.hs`. 
    114113 
    115114{{{ 
     
    168167}}} 
    169168 
    170 The unfixed problem is this (some of the other problems were already addressed): we do an unnecessary stack check on entry to this function. We should eliminate the stack check (and by dead code analysis, the GC call) in such cases. 
     169You can see the up and down behavior here, but that's been fixed, so ignore it for now. (Update the C--!) The unfixed problem is this (some of the other problems were already addressed): we do an unnecessary stack check on entry to this function. We should eliminate the stack check (and by dead code analysis, the GC call) in such cases. 
    171170 
    172171This pattern essentially happens for every function, since we always assign incoming parameters to temporary variables before doing anything. 
     
    174173== Instruction reordering == 
    175174 
    176 We should be able to reorder instructions in order to decrease register pressure. Here's an example from 3586.hs 
     175NEW. We should be able to reorder instructions in order to decrease register pressure. Here's an example from 3586.hs 
    177176 
    178177{{{ 
     
    188187== Stack space overuse == 
    189188 
    190 `T1969.hs` demonstrates this: 
     189CONFIRMED. `T1969.hs` demonstrates this: 
    191190 
    192191{{{