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/