Status and future of the LLVM backend

[Erik de Castro Lopo]

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/