[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 angerman):

 Well, I'm all for someone to ensure that opt and llc work. That's
 fantastic!

 I never intend to actually customize much of clang, opt or llc. However if
 we run into cases again where we have upstream patches that are needed,
 and have even been merged, but there has no llvm release been cut, we will
 need to have some form of customized interim binary.

 As you said it is unknown if apples clang *is* identical or not and which
 customization have been applied. I would still hope we will be able to
 ideally use the systems provided clang at some point. Which of course
 won't work if we need opt, and that is not provided. If we end up
 flat our refusing to use apples clang on ideological grounds, and apple
 ends up customizing their clang to the point where you are required to use
 their clang, or won't be able to take play in their walled garden, do we
 want to make that sacrifice? This of course is hypothetical.

 I would though stay away from ever generating any assembly, and have llvm
 produce object code directly, either via opt+llc, or opt+clang or clang.
 Ideally it should be

    .bc -> [llvm blackbox which allows us to pass flags where and how we
 need it] -> .o

 Switching to haskell bindings for LLVM has been no option for various
 reasons. I don't know if this stand has ever changed. Due to
 this though, I do have a pure haskell bitcode generator
 (https://github.com/angerman/data-bitcode, https://github.com/angerman
 /data-bitcode-llvm, ...) these are by no means complete, the plugin I have
 can compile and link trivial haskell programs; I do plan on integrating
 them into ghc, without the plugin approach, as that requires a significant
 amount of rewriting the plugin interface in ghc.

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