Legend:

* 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

10

10

* 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.

* 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

39

49

* 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).

40

50

* 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.

* 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).

62

61

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.

* 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

74

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.

75

76

=== LLVM's Link Time Optimisations ===

77

78

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. 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

85

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).

86

87

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.