#8971: Native Code Generator for 7.8 is not as optimized as 7.6.3... --------------------------------------------+------------------------------ Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonmar): Replying to [comment:18 carter]:
@simon, so the right path forward is someone putting some engineering time into the new ncg register allocator?
If you mean `-fregs-graph`, then yes, working on that would be a good way to fix this bug. Right now I believe it has regressed since the switch to the new code generator: #7679 Another angle would be to change the calling convention so that we use `%ebx` for R1 on 32-bit platforms. Right now we use `%esi`, which doesn't have an 8-bit version so we can't let the register allocator use it on 32-bit x86 (because neither register allocator can handle the constraint that this reg can't be used for 8-bit calculations). Implementing that is more work than changing the calling convention, but changing the calling convention means doing the same thing in LLVM (and we get a dependency on a new version of LLVM, ugh). Yet another angle would be to make the linear scan allocator sensitive to loops. This might not be too hard, actually: the general plan would be to (a) identify the loops, (b) identify the important loop-carried variables, and (c) assign registers on entry to the loop so that the important variables go into regs. Still, I find it hard to get too excited about any of this when it doesn't affect 64-bit platforms and in any case we can use LLVM. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8971#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler