[GHC] #8971: Native Code Generator for 7.8 is not as optimized as 7.6.3...

[GHC]

#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