Ok. Let's do this. I will deviate a bit from the plan in the proposal
#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 bgamari): Replying to [comment:11 angerman]: 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.
- 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.
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.
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. Thanks for picking this up, angerman! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10074#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler