[GHC] #10074: Implement the 'Improved LLVM Backend' proposal

[GHC]

#10074: Implement the 'Improved LLVM Backend' proposal
-------------------------------------+-------------------------------------
        Reporter:  thoughtpolice     |                Owner:  angerman
            Type:  task              |               Status:  new
        Priority:  high              |            Milestone:  8.4.1
       Component:  Compiler (LLVM)   |              Version:
      Resolution:                    |             Keywords:  llvm, codegen
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #11295, #12470    |  Differential Rev(s):  Phab:D530
       Wiki Page:                    |
  wiki:ImprovedLLVMBackend           |
-------------------------------------+-------------------------------------

Comment (by kavon):

 I personally don't see much of a benefit in moving from llc/opt to clang
 just to merge the interface to LLVM.

 The only benefit I can imagine is that we can skip the step of having opt
 generate a .bc and feeding that into llc, though perhaps we can just pipe
 opt's output directly to llc? This might save some compile time.

 Otherwise, we can build our own opt & llc and include those if we needed a
 custom version of LLVM... which is one of my questions, which particular
 patches for LLVM are needed right now, or is this a preparation step?

 Off the top of my head, I think the downsides of switching to clang as our
 interface to LLVM are:

 - clang limits us to using only the -Ox passes, which are tuned for C/C++.
 There's likely some benefit to crafting/tuning our own sequence of
 optimization passes (which is on my todo list). There are also IR passes
 in LLVM that are not included in the default -Ox sets that could prove
 useful when tuning.
 - Special llc flags such as specifying a special stack alignment might be
 out of reach (not sure how well clang handles options for opt/llc)
 - AFAIK unoptimized GHC builds prioritize compilation time, running
 essentially just mem2reg to introduce phi-nodes before handing off to llc.
 I'm not sure if we can get such customizability with clang. Furthermore,
 I'm worried that clang's -O0 option will choose llc's -O0 option, which is
 a _very_ naive register allocator that I believe was meant to aid
 debugging, because it barely tries to keep values in register from what
 I've seen it produce. Decoupling LLVM IR optimization and LLVM IR machine
 code generation lets us still pick a decent register allocator, for
 example.

 As an FYI, I'm currently [wiki:Commentary/Compiler/BackendOpt working on
 the LLVM backend] too, namely, I'm working on removing proc-point
 splitting when using LLVM.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10074#comment:25>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler