Changelog for llvm-hs-8.0.0
8.0.0 (2019-03-10)
- Upgrade to LLVM 8
- It is now possible to define multiple variables with an empty name
without causing a name collision. Variables with an empty name
cannot be referenced. This fixes an issue caused by using
IRBuilder’s
extern
helper.
7.0.1 (2018-09-29)
- Support llvm-config executables named
llvm-config-7
in addition tollvm-config-7.0
andllvm-config
.
7.0.0 (2018-09-28)
- Throw an
EncodeException
if a local variable is defined multiple times. This is consistent withllc
which also forbids reusing variable names. - Update for LLVM 7.0:
- The ORC JIT API has been changed to reflect the changes in LLVM
itself. The test suite should give you a good idea of how to adapt
your code but here is a summary:
- There is now a separate
ExecutionSession
that tracks module handles. SymbolResolver
only has a single resolver function.- Creating an
ObjectLinkingLayer
requires a way to get the symbol resolver for a module. - Creating a
CompileOnDemandLayer
requires a way to set and get the symbol resolver for a module.
- There is now a separate
- The ORC JIT API has been changed to reflect the changes in LLVM
itself. The test suite should give you a good idea of how to adapt
your code but here is a summary:
6.3.0 (2018-06-12)
findSymbol
andfindSymbolIn
now returnEither JITSymbolError JITSymbol
if the JIT symbol has the error flag set or the address is 0. (This is consistent with how LLVM treats JIT symbols).- The return type of
SymbolResolverFn
has been changed toEither JITSymbolError JITSymbol
. It is fine to return a 0 address inRight
so existing resolvers can be adapted by wrapping the result inRight
. - Fixed a bug where instructions were constant-folded during encoding. This caused problems since the API available on a Constant is not the same as the one on an Instruction (e.g., we cannot set metadata on a Constant).
- Fix use-after-free in
createObjectFile
. - Add
withObjectFile
wrapper forcreateObjectFile
anddisposeObjectFile
. - Add API for looking up symbols in the
LinkingLayer
. - Add
LLVM.OrcJIT.CompileLayer
andLLVM.OrcJIT.LinkingLayer
modules that reexport the internal modules. ThefindSymbol/findSymbolIn
methods that have previously been exported fromLLVM.OrcJIT
can now be found inLLVM.OrcJIT.CompileLayer
.
6.2.0 (2018-05-08)
- Remove field prefixes from
DIDerivedType
,DIBasicType
andDISubroutineType
to make the API consistent with the other debug metadata types. - Change the type of the scope fields in
DIModule
andDINamespace
toMaybe (MDRef DIScope)
to reflect that they can be optional.
6.1.1 (2018-05-06)
- Fix the source distribution by adding missing files to extra-source-files.
6.1.0 (2018-05-05)
- Remove the
MetadataNodeReference
constructor. References to metadata nodes are now encoded using the polymorphicMDRef
type. - Add support for encoding and decoding debug metadata. Thanks to @xldenis who started that effort!
- Drop support for GHC 7.10.
- Support decoding/encoding of metadata in
GlobalVariable
andFunction
. - Fix check that the type of
GlobalReference
is correct in the presence of automatic renamings due to name collisions. - Extract LinkingLayer into a separate module.
6.0.0 (2018-03-06)
- Support for LLVM 6.0, take a look at the changelog of llvm-hs-pure for details.
- Add
AggregateZero
for zero-initializing structs, arrays and vectors. PreviouslyNull
was used for null pointers as well as zero-inializing aggregates. The new behavior reflects LLVM’s internal representation and the C++-API. - Enforce that
Null
is only used on pointer types. Existing uses ofNull
on arrays, structs and vector must be changed to the newly introducedAggregateZero
.
5.1.3 (2018-01-06)
- Add bindings to
loadLibraryPermamently
andgetSymbolAddressInProcess
.
5.1.2 (2017-12-19)
- Reupload of 5.1.1 since Hackage broke during the original upload.
5.1.1 (2017-12-16)
- Fix argument order in
LLVM_Hs_CreateTargetMachine
. This affectswithTargetMachine
andwithHostTargetMachine
. - Add support for
MCTargetOptions
.
5.1.0 (2017-10-12)
Bugfixes
- Set target options in
withTargetMachine
. Previously the options passed there were simply ignored. - Fix decoding of constant vectors.
- Fix decoding of function attributes in calls.
Enhancements
- Support for more target options.
- Suport string attributes as parameter attributes.
- Support more calling conventions.
- Support
NoTail
TailCallKind
.
5.0.0 (2017-09-07)
-
Support for LLVM 5.0
We only give a summary of the changes affecting the public API of
llvm-hs
here. Please refer to the official release notes for LLVM 5.0 for an overview of all changes in LLVM 5.0.- The
X86_64_Win64
calling convention is now calledWin64
. - There is a new
Speculatable
function attribute. - The
CrossThread
synchronization scope has been removed. There is now a newSystem
synchronization scope. - The
OrcJIT
-API now operates on individual modules instead of sets of modules. - The
lessPreciseFloatingPointMultiplyAddOption
field has been removed from the target options. - The
compressDebugSections
option field is now of typeDebugCompressionType
instead ofBool
. - The
BasicBlockVectorize
pass has been removed. You should useSuperwordLevelParallelismVectorize
instead.
- The
-
Throw 'EncodeException' when the type supplied in a 'GlobalReference' does not match the type of the expression.
-
Throw 'EncodeException' when the result of instructions returning void is named using ':='.
4.2.0 (2017-06-20)
- Revamp OrcJIT API
- The user facing API is now exposed using
LLVM.OrcJIT
. - All user facing functions have been documented.
- In addition the bracket-style API, there are now
new*
anddispose*
functions making it easier to ingegrate OrcJIT in custom monad transformer stacks. - There is a new
CompileLayer
typeclass which abstracts over the various compile layers inOrcJIT
.
- The user facing API is now exposed using
- Support QuickCheck 2.10
4.1.0 (2017-05-17)
- Switch most of the API from
String
toByteString
. - Switch from ExceptT to using exceptions.
See
LLVM.Exception
for an overview of the exceptions potentially thrown.
4.0.1
- Fix linking of system libraries
4.0.0 (initial release, changes in comparison to llvm-general)
- Move modules from
LLVM.General*
toLLVM.*
- Support for LLVM 4.0
- Improved support for LLVM’s exception handling instructions
-fshared-llvm
is now supported on windows (thanks to @RyanGLScott)- Default to
-fshared-llvm
- Expose
LLVM.Internal.*
modules.