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

 - if lto depends on gold, than this will clearly only work on ELF based
 systems, I'm not just if lld would solve this though, it's supposed to be
 somewhat stable already.
 - I don't see the STG/C difference in the emails. I might be not reading
 something right though. Yes if we want exact control over opt and llc,
 which we can't get through clang, we will need to revert back to those
 tools. I however would prefer not to. That `clang` or `opt/llc` are
 equally suboptimal is certainly correct. I would argue that one tool is
 preferable over two tools, unless we find actual usecases we can't achieve
 with that single tool (and can not subsequently convince the llvm people
 that our usecase is legit.).
 - Yes, we could ask clang to output assembly, (or bitcode if we wanted to
 use llvms bitcode linkter), and use clang as the assembler as well. I
 simply want to get rid of the mangler if possible (see also #11138); right
 now we use the mangler for three things: a) avx mangling, which I'm not
 certain we still need, and if we need it we should figure out why and fix
 it in llvm upstream. b) function/object rewrites, which I'm suspicious of
 as well (see https://reviews.llvm.org/D30812) and c) the `-dead_strip`
 fix, which we do not need with llvm5 or a patched llvm4 anymore and only
 affects mach-o based systems (iOS, macOS, ...) anyway.
 - Dropping the dreaded module layout / header logic was a long time goal
 of mine, as it is not only painful to keep those up to date, and I'm not
 even sure we have the proper values.

 As the Imrpoved LLVM Proposal was about bundling llvm **with** ghc, to
 have better control over the llvm backend, bundling clang (or if we really
 must opt+llc) looks to me like the way to go. Ideally though, I'd prefer
 to find all necessary fixes we need in llvm and have them upstreamed in
 llvm5, such that ghc8.4 can simply require llvm5.  However I'm not opposed
 to laying the foundation to bundle clang with ghc, should the need arise.

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