Changes between Version 7 and Version 8 of Commentary/Compiler/Backends/LLVM/DevelopmentNotes


Ignore:
Timestamp:
Jun 11, 2010 11:06:57 AM (4 years ago)
Author:
dterei
Comment:

move design issues into here

Legend:

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

    v7 v8  
    11[[PageOutline]] 
    22= Bugs & Other Problems = 
     3 
     4This page lists bugs and problems currently known about in the LLVM backend. 
     5 
     6= Unsupported GHC Features = 
     7 
     8== Threaded == 
     9 
     10Dynamic 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. 
     11 
     12== TABLES_NEXT_TO_CODE == 
     13 
     14GHC for heap objects places the info table (meta data) and the code adjacent to each other. That is, in memory, the object firstly has a head structure, which consists of a pointer to an info table and a payload structure. The pointer points to the bottom of the info table and the closures code is placed to be straight after the info table, so to jump to the code we can just jump one past the info table pointer. The other way to do this would be to have the info table contain a pointer to the closure code. However this would then require two jumps to get to the code instead of just one jump in the optimised layout. Achieving this layout can create some difficulty, the current back-ends handle it as follows: 
     15 
     16  * The NCG can create this layout itself 
     17  * The C code generator can't. So the [wiki:Commentary/EvilMangler Evil Mangler] rearranges the GCC assembly code to achieve the layout.  
     18 
     19There is a build option in GHC to use the unoptimised layout and instead use a pointer to the code in the info table. This layout can be enabled/disabled by using the compiler {{{#def TABLES_NEXT_TO_CODE}}}. As LLVM has no means to achieve the optimised layout and we don't wish to write an LLVM sister for the Evil Mangler, the LLVM back-end currently uses the unoptimised layout. This apparently incurs a performance penalty of 5% (source, Making a ''Fast Curry: Push/Enter vs. Eval/Apply for Higher-order Languages'', Simon Marlow and Simon Peyton Jones, 2004). 
    320 
    421= LLVM Bugs =