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

 Replying to [comment:12 bgamari]:
 > Replying to [comment:11 angerman]:
 > > Ok. Let's do this. I will deviate a bit from the plan in the proposal
 though. The rough idea is:
 > >
 > > - replace opt+llc with clang. This does imply that we loose the
 mangler, and probably won't be able to do `-split-obj` at all.
 >
 > I won't lose much sleep over losing split objects. Frankly, I look
 forward to the day when we can drop it entirely. However, it seems like
 the the mangler/AVX situation may be a bit trickier.
 >
 As I've just said on irc, I wonder, assuming we did the obj-splitting at
 the cmm level, wouldn't we get split-obj for free in ncg and llvm? Yet, as
 [dobenour] mentioned, this would likely prevent inlining in the llvm
 backend.

 > > - build a release llvm-clang with necessary ghc changes, and call this
 `ghc-clang`, until we all ghc relevant patches are upstream in llvm.
 > > - provide binary distributions for said `ghc-clang` for at least all
 tire1 platforms. Other platform will have to build clang from source.
 > >
 > As we discussed on IRC, I really would like to avoid coming to rely on
 our own LLVM builds if possible. Let's instead try to just get the patches
 we need upstream if at all possible. Then we can just piggy-back on the
 upstream LLVM binary distributions.
 Yes this would be ideal. I'm just not convinced (with our track record),
 that we won't find some llvm fix we need just in time so it doesn't make
 it into llvm5.
 >
 > > This should hopefully allow us to drop quite a bit of code from the
 llvm backend. It might re-introduce some new bugs. We do have quite a few
 hacks here and there to work around bugs in the llvm toolchain, for which
 we do not necessarily know if they are still present in the llvm toolchain
 we currently support.
 > >
 > Can you list these? I tried to think of what this refers to but I can't
 think of anything off the top of my head.
 There are some of comments in the opt and llc phases, referring to bugs
 (e.g. macOS doesn't properly do -O3). Now dropping opt and llc and going
 just via clang, we do loose some control over the specific optimization
 flags we can pass, but in return get a stable unified interface.
 >
 > > This should allow us to pin the llvm backend to a certain (potentially
 customized) clang version. This should be an interim solution only though.
 Hopefully we'll have all the necessary changes in llvm upstreamed by the
 time llvm5 (~6mo from now) or llvm6 (~12mo from now), will be released.
 >
 > Right. I see no real reason why it should take longer than six months to
 get our changes upstream.

 On a final note: actually building a custom (static) clang to distribute
 seems rather simple. I've a makefile or ~10 lines that I believe would
 also work on linux and bsds; windows would need to be figured out.

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