llvm-tf

Bindings to the LLVM compiler toolkit using type families.

Latest on Hackage:3.1.0.2

This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow stackage.org to host generated Haddocks.

BSD3 licensed by Henning Thielemann, Bryan O'Sullivan, Lennart Augustsson
Maintained by Henning Thielemann

High-level bindings to the LLVM compiler toolkit using type families instead of functional dependencies.

We use the same module names as the llvm package, which makes it harder to work with both packages from GHCi. You may use the -hide-package option. We may change the module names later.

A note on versioning: The versions of this package are loosely based on the LLVM version. However, we depend on a relatively stable part of LLVM and provide a relatively stable API for it. We conform to the Package Versioning Policy PVP, i.e. we increase the version of this package when its API changes, but not necessarily when we add support for a new LLVM version. We support all those LLVM versions that are supported by our llvm-ffi dependency.

Changes

Change log for the llvm-tf package

3.1.0.1

  • addFunctionMapping checks for functions that are eliminated by optimization passes. This fixes a crash when working with optimizations and call-back functions.

3.1

  • ExecutionEngine is now managed by a ForeignPtr with a finalizer. That is, you must keep the ExecutionEngine alive as long as you call compiled functions.

    FreePointers and getFreePointers are gone.

3.0.3

  • constVector, constArray, vector do no longer cycle the vector Instead they check for the appropriate static length.

  • FFI.constVector, FFI.constArray must be in IO in order to proper sequence actions in Core.Util.constVector, Core.Util.constArray. Currently, in Util.constVector it is possible that FFI.constArray is called too late and thus operates on a released pointer.

comments powered byDisqus