|Version 19 (modified by dterei, 4 years ago) (diff)|
Bugs & Other Problems
This page lists bugs and problems currently known about in the LLVM backend.
Unsupported GHC Features
Dynamic library support hasn't been tested at all in the LLVM backend. No work has been done on it. Its very unlikely that this feature works in the LLVM backend at the moment.
GHC LLVM Back-end Bugs
Stack Alignment on OSX
On OSX the ABI requires that the stack is 16 byte aligned when making function calls. (Although this only really needs to be obeyed when making calls that will go through the dynamic linker, so FFI calls). Since the stack is 16 byte aligned at the site of the call, on entry to a function most compilers (both llvm and gcc) expect the stack to now be aligned to 16n - 4, since 4 bytes should have been pushed for the return address as part of the call instruction. GHC though since it uses jumps everywhere keeps that stack at 16 byte aligned on function entrance. This means that LLVM generates incorrect stack alignment code, always off by 4.
For the moment I have handled this by using the LLvm Mangler (which is only needed on OS X already for TNTC) to simply correctly fix up the stack alignment code.
E.g Asm generated by LLVM:
_func: subl $12, %esp ... call _sin ... addl $12, %esp
The mangler will change this to:
_func: subl $16, %esp ... call _sin ... addl $16, %esp
The better solution would be to change GHC to keep the stack at 16n - 4 alignment on function. This will require changing the RTS (StgCRun.hs) to set the stack properly before calling into Stg land and also fixing up the NCG to align code properly. There may also be a problem with the C backend as currently all function prolouge and epilouge code is stripped out, which means all the stack manipulation code generated by GCC is removed. This works fine now since the stack is already 16 byte aligned on entry, but if it is now 16n - 4 byte aligned then some stack manipulation will be required.
QuickHull (DPH Example, OSX)
The Quickhull example segfaults under OS X.