Changes between Version 20 and Version 21 of Commentary/Compiler/NewCodeGenStupidity
- Timestamp:
- 04/16/11 12:31:43 (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Commentary/Compiler/NewCodeGenStupidity
v20 v21 5 5 == Lots of temporary variables == 6 6 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.7 WONTFIX. 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. 8 8 9 9 ~~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. … … 13 13 == Rewriting stacks == 14 14 15 `3586.hs` emits the following code:15 FIXED. `3586.hs` emits the following code: 16 16 17 17 {{{ … … 59 59 Since 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. 60 60 61 This looks fixed with the patch from April 14 , though there are still other problems with this file.61 This looks fixed with the patch from April 14. 62 62 63 63 == Spilling Hp/Sp == 64 64 65 66 `3586.hs` emits the following code: 65 FIXED. `3586.hs` emits the following code: 67 66 68 67 {{{ … … 95 94 ~~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. 96 95 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.96 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. 98 97 99 98 == Up and Down == 100 99 101 A frequent pattern is the stack pointer being bumped up and then back down again, for no particular reason.100 FIXD. A frequent pattern is the stack pointer being bumped up and then back down again, for no particular reason. 102 101 103 102 {{{ … … 111 110 == Sp is generally stupid == 112 111 113 Here is an optimized C-- sample from `arr016.hs`.112 CONFIRMED. Here is an optimized C-- sample from `arr016.hs`. 114 113 115 114 {{{ … … 168 167 }}} 169 168 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.169 You 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. 171 170 172 171 This pattern essentially happens for every function, since we always assign incoming parameters to temporary variables before doing anything. … … 174 173 == Instruction reordering == 175 174 176 We should be able to reorder instructions in order to decrease register pressure. Here's an example from 3586.hs175 NEW. We should be able to reorder instructions in order to decrease register pressure. Here's an example from 3586.hs 177 176 178 177 {{{ … … 188 187 == Stack space overuse == 189 188 190 `T1969.hs` demonstrates this:189 CONFIRMED. `T1969.hs` demonstrates this: 191 190 192 191 {{{
