Changes between Version 15 and Version 16 of Commentary/Compiler/Backends/LLVM/DevelopmentNotes


Ignore:
Timestamp:
Jul 18, 2010 4:12:00 PM (4 years ago)
Author:
dterei
Comment:

Update for recent changes

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/Backends/LLVM/DevelopmentNotes

    v15 v16  
    1212== GHC LLVM Back-end Bugs == 
    1313 
    14 === Foreign Calls on Mac OSX === 
     14=== Stack Alignment on OSX === 
    1515 
    16 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. 
     16On 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. 
    1717 
    18 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. 
     18For 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. 
    1919 
    20 Update (07/07/10): Issue still exists. 
     20E.g Asm generated by LLVM:  
    2121 
    22 '''Solutions''': 
    23  * A new function attribute has just landed in SVN which allows stack alignment to be specified when a call is made. 
    24  * Can use inline assembler to fix stack alignment. 
    25  * Fix stack calculation in LLVM (my changes must have broken it). 
     22_func: 
     23    subl $12, %esp 
     24    ... 
     25    call _sin 
     26    ... 
     27    addl $12, %esp 
    2628 
    27 === Repa examples - FFT segfaults === 
     29The mangler will change this to: 
    2830 
    29 If you run the FFT program form [http://hackage.haskell.org/package/repa-examples repa-examples], it segfaults under the LLVM backend. 
     31_func: 
     32    subl $12, %esp 
     33    ... 
     34    call _sin 
     35    ... 
     36    addl $12, %esp 
     37 
     38The 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. 
     39 
     40=== QuickHull (DPH Example, OSX) === 
     41 
     42The Quickhull example segfaults under OS X.