Ben Gamari wrote:
> I've written down some thoughts on the current status and future
> direction of the LLVM backend here [1]. Have a look when you get a chance.
>
> To summarize,
>
> * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework
> when the `$def` symbols are marked as internal
>
> * ARM is broken (again) due to a bug in the GHC calling convention
> implementation; an LLVM fix is waiting to be merged
>
> * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6
> support will likely need to wait until 7.12
>
> * Austin's LLVM packaging proposal seems very much like the right way
> forward
>
> * Anticipating this proposal, I have started collecting [2]
> optimization passes
I've recently been working on amd64-linux to armhf-linux and aarch64-linux
cross-compilers. In addition to the above:
* LLVM 3.6 that Ben mentions above has not yet been released and is
still a work in progress. A commit to the LLVM tree made as recently
as December 17th means LLVM head no longer compiles LLVM IR code
generated by GHC (metadata issue mentioned in #9920).
* LLVM uses C/C++ asserts liberally and these asserts get compiled out
during optimised builds (eg for Linux distributions). The removal of
these asserts results in llvm binaries that *silently* generate
incorrect binaries (see #9920 which is Ben's second bullet point above).
For instance, I built an amd64-linux to aarch64-linux cross compiler
which generated executables that crashed immediately. When I switched
to a debug version of LLVM, LLVM's opt and llc suddenly started showing
assertion failures all over.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
