summaryrefslogtreecommitdiff
path: root/compiler/llvmGen/Llvm.hs
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Llvm (#13009)Sylvain Henry2020-02-181-64/+0
|
* llvmGen: Make metadata ids a newtypeBen Gamari2016-06-181-1/+1
| | | | | These were previously just represented as Ints which was needlessly vague.
* LLVM: Implement atomic operations in terms of LLVM primitivesBen Gamari2015-10-021-0/+3
| | | | | | | | | | | | | | | | | | | This fixes Trac #7883. This adds proper support for, * `MO_AtomicRMW` * `MO_AtomicWrite` * `MO_CmpXChg` Test Plan: Validate Reviewers: rrnewton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1282 GHC Trac Issues: #7883
* Extend globals to aliasesPeter Wortmann2013-06-271-2/+3
| | | | | Also give them a proper constructor - getGlobalVar and getGlobalValue map directly to the accessors.
* Use SDoc for all LLVM pretty-printingPeter Wortmann2013-06-271-1/+2
| | | | | | | This patch reworks some parts of the LLVM pretty-printing code that were still using Show and String. Now we should be using SDoc and Outputable throughout. Note that many get*Name functions become pp*Name here as a side-effect.
* Iteration on dterei's metadata designPeter Wortmann2013-06-271-2/+2
| | | | | | | | | | | | | | | | | | | | | - MetaArgs is not needed, as variables are already meta data - Same goes for MetaVal - its only reason for existing seems to be to support LLVM's strange pretty-printing for meta-data annotations, and I feel that is better to keep the data structure clean and handle it in the pretty-printing instead. - Rename "MetaData" to "MetaAnnot". Meta-data is still meta-data when it is not associated with an expression or statement - for example compile unit data for debugging. I feel the old name was a bit misleading. - Make the renamed MetaAnnot a proper data type instead of a type alias for a pair. - Rename "MetaExpr" constructor to "MetaStruct". As the data is much more like a LLVM structure (not array, as it can contain values). - Fix a warning
* Add ability to call functions with metadata as arguments to LLVMDavid Terei2013-06-271-1/+1
| | | | backend.
* Rework LLVM metadata representation to be more accurate.David Terei2013-06-271-1/+2
|
* Add support for LLVM vectors.Geoffrey Mainland2013-02-011-1/+1
| | | | | This patch adds support for LLVM vectors and vector operations to our internal LLVM abstract syntax data types.
* Use SDoc rather than Doc in LLVMIan Lynagh2012-06-121-1/+0
| | | | | In particular, this makes life simpler when we want to use a general GHC SDoc in the middle of some LLVM.
* llvmGen: Use new fence instructionBen Gamari2012-01-301-0/+3
| | | | Signed-off-by: David Terei <davidterei@gmail.com>
* Add Metadata support to LLVM bindings.David Terei2012-01-121-1/+5
|
* LLVM: Add alias type defenitions to LlvmModule.David Terei2010-07-071-2/+2
|
* Add support for parameter attributes to the llvm BE bindingDavid Terei2010-06-241-0/+1
| | | | | | These allow annotations of the code produced by the backend which should bring some perforamnce gains. At the moment the attributes aren't being used though.
* Declare some top level globals to be constant when appropriateDavid Terei2010-06-211-5/+4
| | | | | | | This involved removing the old constant handling mechanism which was fairly hard to use. Now being constant or not is simply a property of a global variable instead of a separate type.
* Add support of TNTC to llvm backendDavid Terei2010-06-181-4/+4
| | | | | | | We do this through a gnu as feature called subsections, where you can put data/code into a numbered subsection and those subsections will be joined together in descending order by gas at compile time.
* Add new LLVM code generator to GHC. (Version 2)David Terei2010-06-151-0/+52
This was done as part of an honours thesis at UNSW, the paper describing the work and results can be found at: http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf A Homepage for the backend can be found at: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM Quick summary of performance is that for the 'nofib' benchmark suite, runtimes are within 5% slower than the NCG and generally better than the C code generator. For some code though, such as the DPH projects benchmark, the LLVM code generator outperforms the NCG and C code generator by about a 25% reduction in run times.
View Lorry Controller Status