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

 My current plan is to do [opt +] clang, and having opt disabled by
 default, until someone has the time to investigate different opt
 configurations. Piping opt to llc, would still incur serialization and
 deserialization overhead.  My current standpoint is, that unless we
 explicitly gain something by using opt + clang or opt + llc right now, I'd
 rather have a dumb and simple solution.

 Regarding LTO, I believe we can do LTO at the bitcode level with `llvm-
 link` and `opt`. However this would need to be explored,
 and until done so, I'd rather have a simple solution.

 The opt+llc -> clang diff I posted to phabricator clamps the `-O` in
 `[1,3]`.  Such that we always get mem2reg; the current design
 doesn't allow to trivially pass `-Os` I'm afraid, as ghc expects `-O` to
 be numeric.

 In general clang doesn't really handle `opt` or `llc` flags or passes them
 down properly. There are supposed to be some escape hatches but afaict
 they do not cover all cases. Thus we'd be left with what clang offers. Yet
 again I'd like to stress the point that someone would need to seriously
 take ownership of the opt/llc code, ensure that all the hacks are still
 necessary, that opt and llc flags match up, and ensure that they work with
 new llvm version.

 While bundling llvm would lessen the need to care for the latter, I
 imagine we'd still want to upgrade llvm from time to time?

 What I hope to be able to complete this year is:
 - simplify the llvm logic: replacing opt+llc with opt+clang or clang for
 the time being
 - integrating the Data.BitCode modules to directly generate BitCode IR
 (without so much aliasing) from GHC
 - try to see if we can teach GHC that BitCode is a valid object like
 format.

 The last point being essential to use llvm-link.

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