... | ... | @@ -12,24 +12,44 @@ Dynamic library support hasn't been tested at all in the LLVM backend. No work h |
|
|
|
|
|
## GHC LLVM Back-end Bugs
|
|
|
|
|
|
### Foreign Calls on Mac OSX
|
|
|
### Stack Alignment on OSX
|
|
|
|
|
|
|
|
|
Foreign calls on Mac OS X don't work. Seems to be because LLVM isn't generating correct code. All system calls must be 16 byte aligned in OS X and llvm isn't respecting this. Not sure if its a bug in LLVM or due to my changes to LLVM.
|
|
|
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.
|
|
|
|
|
|
|
|
|
Update (20/02/10): I fixed this issue using the inline assembler approach (see below). This reduces the test failures on Mac OSX from 22 to 9. So doesn't fix everything. Still other issues. Also, I tried using the new stalk alignment feature but that interacts badly with the GHC calling convention, clobbering the Base register.
|
|
|
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.
|
|
|
|
|
|
|
|
|
Update (07/07/10): Issue still exists.
|
|
|
E.g Asm generated by LLVM:
|
|
|
|
|
|
**Solutions**:
|
|
|
|
|
|
- A new function attribute has just landed in SVN which allows stack alignment to be specified when a call is made.
|
|
|
- Can use inline assembler to fix stack alignment.
|
|
|
- Fix stack calculation in LLVM (my changes must have broken it).
|
|
|
_func:
|
|
|
|
|
|
### Repa examples - FFT segfaults
|
|
|
>
|
|
|
> subl $12, %esp
|
|
|
> ...
|
|
|
> call _sin
|
|
|
> ...
|
|
|
> addl $12, %esp
|
|
|
|
|
|
|
|
|
If you run the FFT program form [ repa-examples](http://hackage.haskell.org/package/repa-examples), it segfaults under the LLVM backend. |
|
|
The mangler will change this to:
|
|
|
|
|
|
|
|
|
_func:
|
|
|
|
|
|
>
|
|
|
> subl $12, %esp
|
|
|
> ...
|
|
|
> call _sin
|
|
|
> ...
|
|
|
> addl $12, %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. |