#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