Changes between Version 8 and Version 9 of Commentary/Compiler/Backends/LLVM/WIP


Ignore:
Timestamp:
Jun 11, 2010 10:34:17 AM (4 years ago)
Author:
dterei
Comment:

Add in small todo notes and rearrange big items to reflect order of importance somewhat

Legend:

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

    v8 v9  
    99   * Max Bolingbroke (http://www.cl.cam.ac.uk/~mb566) has proposed a SoC project to work on LLVM http://hackage.haskell.org/trac/summer-of-code/ticket/1582 
    1010   * Alp Mestanogullari (http://alpmestan.wordpress.com/, http://twitter.com/alpmestan) is interested in working on a SoC project on LLVM 
     11 
     12== Small Ticket Items == 
     13 
     14 * Use a new Monad instead of passing `LlvmEnv` around everywhere. 
     15 * Should be able to put all `CmmProc` and `CmmData` labels in environment at start and after that, can print out LLVM IR as I generate it for each data and proc instead of storing. 
     16 * Look at using LLVM intrinsic functions. There are a few math functions. Also, there is a `smul_overflow` detect function. 
     17 * Rearrange some functions and files better. 
     18 * handling of `LlvmVar` or `LlvmType` for function signature isn't nice. Whole function signature handling could be better really. We also don't support parameter attributes which we should enable for better performance. 
     19 * {{{LlvmCodeGen.CodeGen.genCall}}} code for foreign calls is quite complex, could use a clean-up. 
    1120 
    1221== Big Ticket Items == 
     
    3746 
    3847 * Update the back-end to use some of the new features of LLVM 2.6 and 2.7. Currently it only uses features of 2.5. (e.g could maybe use the new LLVM integer specific add operation to detect overflow rather then the current custom code to do it). One quick improvement is that as of 2.7 the LLVM assembler ('llvm-as') stage in the LLVM back-end pipeline isn't needed now at the LLVM optimiser tool ('opt') can be directly given LLVM assembly now as well as LLVM bitcode. 
     48 * All the STG registers are passed around at the moment as just words. Some really should be passed as pointer type (e.g Sp, Hp). We can then use the noalias attribute on them which is useful. Also the nocapture attribute 
    3949 * Look into the various [http://llvm.org/docs/LangRef.html#paramattrs parameter attributes] and [http://llvm.org/docs/LangRef.html#fnattrs function attributes] that LLVM supports and how they should be used by the LLVM back-end. (e.g the noalias parameter attribute should probably be used). 
    4050 * Look at the various [http://llvm.org/docs/LangRef.html#intrinsics intrinsic functions] supported by LLVM. Some of them could maybe be used to replace existing code in LLVM or calls to the rts. (e.g Cmm expects support of a fair number of basic math operations [e.g sin], for which LLVM intrinsic functions exists. However the back-end currently calls the C library for them). 
    41  
    42 === Update the Back-end to use the new Cmm data types / New Code Generator === 
    43  
    44 There is ongoing work to produce a new, nicer, more modular code generator for GHC (the slightly confusingly name code generator in GHC refers to the pipeline stage where the Core IR is compiled to the Cmm IR). The LLVM back-end could be updated to make sure it works with the new code generator and does so in an efficient manner. 
    45  
    46 === LLVM's Link Time Optimisations === 
    47  
    48 One of LLVM's big marketing features is its support for link time optimisation. This does thinks such as in-lining across module boundaries, more aggressive dead code elimination... ect). The LLVM back-end could be updated to make use of this. 
    49  
    50  * [http://llvm.org/releases/2.6/docs/LinkTimeOptimization.html] 
    51  * [http://llvm.org/docs/GoldPlugin.html] 
    5251 
    5352=== Optimise LLVM for the type of Code GHC produces === 
     
    6160 * Look at general fixes/improvement to LLVM to improve the code it generates for LLVM (e.g at the moment LLVM performs a lot of redundant stack manipulation in the code in generates for GHC, would be good to fix this up). 
    6261 
    63 === LLVM Cross Compiler / Port === 
    64  
    65 This is more of an experimental idea but the LLVM back-end looks like it would make a great choice for Porting LLVM. That is, instead of porting LLVM through the usual route of via-C and then fixing up the NCG, just try to do it all through the LLVM back-end. As LLVM is quite portable and supported on more platforms then GHC, it would be an interesting and valuable experiment to try to port GHC to a new platform by simply getting the LLVM back-end working on it. (The LLVM back-end works in both unregistered and registered mode, another advantage for porting compared to the C and NCG back-ends). 
    66  
    67 It would also be interesting to looking into improving GHC to support cross compiling and doing this through the LLVM back-end as it should be easier to fix up to support this feature than the C or NCG back-ends. 
    68  
    6962=== Stabilise / Bug Fixing === 
    7063 
     
    7669 * LLVM back-end is out of tree currently. 
    7770 * Back-end can be reduced in size and use faster data structures (FastString instead of String, OrdList instead of List, might be able to get rid of the environment used by the back-end as I believe the label naming convention stores may store enough information for the back-ends uses). 
     71 
     72=== Update the Back-end to use the new Cmm data types / New Code Generator === 
     73 
     74There is ongoing work to produce a new, nicer, more modular code generator for GHC (the slightly confusingly name code generator in GHC refers to the pipeline stage where the Core IR is compiled to the Cmm IR). The LLVM back-end could be updated to make sure it works with the new code generator and does so in an efficient manner. 
     75 
     76=== LLVM's Link Time Optimisations === 
     77 
     78One of LLVM's big marketing features is its support for link time optimisation. This does thinks such as in-lining across module boundaries, more aggressive dead code elimination... ect). The LLVM back-end could be updated to make use of this. Roman apparently tried to use the new 'gold' linker with GHC and it doesn't support all the needed features. 
     79 
     80 * [http://llvm.org/releases/2.6/docs/LinkTimeOptimization.html] 
     81 * [http://llvm.org/docs/GoldPlugin.html] 
     82 
     83=== LLVM Cross Compiler / Port === 
     84 
     85This is more of an experimental idea but the LLVM back-end looks like it would make a great choice for Porting LLVM. That is, instead of porting LLVM through the usual route of via-C and then fixing up the NCG, just try to do it all through the LLVM back-end. As LLVM is quite portable and supported on more platforms then GHC, it would be an interesting and valuable experiment to try to port GHC to a new platform by simply getting the LLVM back-end working on it. (The LLVM back-end works in both unregistered and registered mode, another advantage for porting compared to the C and NCG back-ends). 
     86 
     87It would also be interesting to looking into improving GHC to support cross compiling and doing this through the LLVM back-end as it should be easier to fix up to support this feature than the C or NCG back-ends.