Displaying 10 results from an estimated 10 matches for "lltype".
Did you mean:
l_type
2010 Feb 18
6
[LLVMdev] ocaml survey
...d some functions? Module providers
are being removed for 2.7. I can keep the old functions around, but
I'd prefer to keep the API clean.
3. Are there any llvm functionality that you need exposed to ocaml?
Right now I plan to expose:
add Union to TypeKind.t
external union_type: llcontext -> lltype array -> lltype
external union_element_types : lltype -> lltype array
external build_indirect_br : llvalue -> int -> llbuilder -> llvalue
external add_destination: llvalue -> llbasicblock -> unit
external build_nsw_add : llvalue -> llvalue -> string -> llbuilder -&g...
2010 Feb 19
0
[LLVMdev] ocaml survey
...d for 2.7. I can keep the old functions around, but
> I'd prefer to keep the API clean.
Knock yourself out.
> 3. Are there any llvm functionality that you need exposed to ocaml?
> Right now I plan to expose:
>
> add Union to TypeKind.t
> external union_type: llcontext -> lltype array -> lltype
> external union_element_types : lltype -> lltype array
>
> external build_indirect_br : llvalue -> int -> llbuilder -> llvalue
> external add_destination: llvalue -> llbasicblock -> unit
>
> external build_nsw_add : llvalue -> llvalue -&...
2010 Feb 18
0
[LLVMdev] ocaml survey
...the API clean.
Fine by me.
> 3. Are there any llvm functionality that you need exposed to ocaml?
Nope. The only feature I'd like is exceptions on the OCaml side from LLVM
errors.
> Right now I plan to expose:
>
> add Union to TypeKind.t
> external union_type: llcontext -> lltype array -> lltype
> external union_element_types : lltype -> lltype array
>
> external build_indirect_br : llvalue -> int -> llbuilder -> llvalue
> external add_destination: llvalue -> llbasicblock -> unit
>
> external build_nsw_add : llvalue -> llvalue ->...
2008 Mar 04
1
[LLVMdev] [PATCH] Prefer to use *.opt ocaml executables as they are more efficient.
I noticed that the ocaml compilation isn't using the .opt
executables if they're available. We might gain a slight
optimization in ocaml compile time by optionally using them
with this patch.
---
autoconf/configure.ac | 18 +++++
configure | 195 ++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 188 insertions(+), 25 deletions(-)
-------------- next part
2008 Mar 04
0
[LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation.
...ntainer for all other LLVM Intermediate
> Representation (IR)
> - * objects. See the llvm::Module class.
> + * objects. See the [llvm::Module] class.
> */
> typedef struct LLVMOpaqueModule *LLVMModuleRef;
>
> /**
> - * Each value in the LLVM IR has a type, an instance of [lltype].
> See the
> - * llvm::Type class.
> + * Each value in the LLVM IR has a type, an instance of
> [LLVMTypeRef]. See the
> + * [llvm::Type] class.
> */
> typedef struct LLVMOpaqueType *LLVMTypeRef;
>
> /**
> - * When building recursive types using [refine_type], [l...
2008 Mar 04
1
[LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation.
---
bindings/ocaml/llvm/llvm.ml | 2 +-
bindings/ocaml/llvm/llvm.mli | 2 +-
bindings/ocaml/llvm/llvm_ocaml.c | 2 +-
include/llvm-c/Core.h | 32 +++++++++++++++++++-------------
4 files changed, 22 insertions(+), 16 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff
Type:
2008 Mar 15
0
[LLVMdev] improving the ocaml binding's type safety
...I think it will also be necessary to provide a
new class of functions, a set of type checking helpers which play the
same role as bool T::isa<U>(T*), U* T::cast<U>(T*), and U*
T::dyn_cast<U>(T*):
(** @see [bool Type::isa<FunctionType>(Type*)] *)
val is_function_type : lltype t -> bool
(** @see [FunctionType *Type::dyn_cast<FunctionType>(Type*)]
@raise Invalid_cast if the conversion is impossible. *)
val as_function_type : lltype t -> `FunctionTy t
For Value, it will be important to push the ISA routines through all
of the layers (esp. for Value), b...
2008 Mar 15
4
[LLVMdev] improving the ocaml binding's type safety
I was talking to Gordon on #llvm earlier, and he challenged me with
coming up with a way to improve the ocaml binding's type safety. We
can't go letting haskell beat us now, can we? I think I got an easy
solution with phantom types.
For those who don't know what the problem is, the ocaml bindings share
one type between whole class branches (like values). This means we
need to downcast
2008 Mar 16
0
[LLVMdev] improving the ocaml binding's type safety
On Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen
<gordonhenriksen at mac.com> wrote:
> After some experimentation, I'd prefer the closed system. LLVM has some type
> peculiarities like the commonality between CallInst and InvokeInst. I find
> that the closed type system lets me express such constraints more naturally.
> Expressing these constraints explicitly in the open
2008 Mar 16
2
[LLVMdev] improving the ocaml binding's type safety
Erick,
After some experimentation, I'd prefer the closed system. LLVM has
some type peculiarities like the commonality between CallInst and
InvokeInst. I find that the closed type system lets me express such
constraints more naturally. Expressing these constraints explicitly in
the open system involves annotating the C++ class hierarchy with extra
variants which are unnecessary in