[GHC] #10074: Implement the 'Improved LLVM Backend' proposal

GHC ghc-devs at haskell.org
Fri Mar 17 01:27:46 UTC 2017


#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:18 awson]:
 > Well, perhaps I was not quite correct.
 >
 > I mostly had in mind things like (for example) `clang` on Windows
 doesn't supporting `-flto`, but using separate utilities, e.g doing `llvm-
 link` between `opt` and `llc` we can accomplish the thing.
 >
 > OTOH, we still can call `clang` twice, first instead of `opt` then
 instead of `llc` with `llvm-link` in-between.
 >
 > Still I'm very much not sure we need to bother with the beast like
 `clang` to only be able to get rid of literally a couple of lines of
 haskell code. Moreover, I'm not sure OS X -O3 example is quite relevant
 here. Do you mean using `-O3` with `opt` and/or `llc` driver yields
 different results from if we use the same `-O3` with `clang` driver on the
 same version of llvm/clang?

 The actual diff is here: https://phabricator.haskell.org/D3352, which you
 might or might now have seen.

 Maybe the `-flto` on windows has changed with llvm4 already? We could I
 guess, do two clang runs, my intention though is to replace

 `ghc -> llvm ir -> opt -> llc -> mangler -> as -> object`

 to

 `ghc -> llvm ir -> clang -> object`.

 The mentioned macOS `-O3` bug, referred to the following lines,
 which sadly do not say which llvm version exhibited the issue.

 {{{
 -- Bug in LLVM at O3 on OSX.
 llvmOpts = if platformOS (targetPlatform dflags) == OSDarwin
            then ["-O1", "-O2", "-O2"]
            else ["-O1", "-O2", "-O3"]
 }}}

 I'm proposing to take this opportunity and start from a blank
 slate and drop any **maybe it's still broken, maybe not** parts
 from the pipeline.

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


More information about the ghc-tickets mailing list