similar to: [LLVMdev] Duplicate wrapper function in LLVM-C.

Displaying 10 results from an estimated 10 matches similar to: "[LLVMdev] Duplicate wrapper function in LLVM-C."

2008 Mar 04
0
[LLVMdev] [PATCH] Cleanup the c and ocaml binding documentation.
Hi Erick, Thanks, this looks good. Can you please resubmit this patch, and the others, as an attachment? On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > --- > 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 ++++++++++++++++++ > +-------------
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
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:
2011 Jun 27
1
[LLVMdev] LLVMdev Digest, Vol 84, Issue 44
Chris, good to see the AbstractType stuff vaporize, but I still have a question, the Type system seems to have a "shadow type" system, every user Type created also has a corresponding XYZValType, is the "shadow type" system still retained ? It's purpose seems(?) to be for factoring the "unique-ing" logic out of the rest of the type system
2011 Jun 24
0
[LLVMdev] inefficiencies in ConstantUniqueMap ?
On Jun 24, 2011, at 8:28 AM, Jay Foad wrote: > Hi, > > Consider ConstantUniqueMap::getOrCreate() (in lib/VMCore/ConstantsContext.h): > > /// getOrCreate - Return the specified constant from the map, creating it if > /// necessary. > ConstantClass *getOrCreate(const TypeClass *Ty, ValRefType V) { > MapKey Lookup(Ty, V); > ConstantClass* Result = 0; > ...
2011 Jun 24
2
[LLVMdev] inefficiencies in ConstantUniqueMap ?
Hi, Consider ConstantUniqueMap::getOrCreate() (in lib/VMCore/ConstantsContext.h): /// getOrCreate - Return the specified constant from the map, creating it if /// necessary. ConstantClass *getOrCreate(const TypeClass *Ty, ValRefType V) { MapKey Lookup(Ty, V); ConstantClass* Result = 0; ... For array (or struct or vector) constants, typically: ValType = vector<Constant*>
2010 Jan 06
2
[LLVMdev] Correct way to resolve recursive type information?
Hi, I've followed the instructions on constructing recursive types ( http://llvm.org/docs/ProgrammersManual.html#BuildRecType) and I can succesfully create simple recursive types using the C bindings (e.g. struct Test { struct Test *t };). I want to generalize this to get type information from my language into generated LLVM code. My language allows arbitrary forward type declarations that I
2008 Sep 08
3
[LLVMdev] Problems when refining type
Hi I'm using the llvm-c wrapper, and trying to build some recursive types (using released 2.3). I get an assert on trying to create a second opaque pointer type after refining a first. The first time through creating an opaque pointer type, a new type is created and returned from PointerType::get, but the second time, ValueType (the opaque type) is found in the PointerTypes map, which seems
2010 Jan 06
0
[LLVMdev] Fwd: Correct way to resolve recursive type information?
2010/1/6 Talin <viridia at gmail.com> In my compiler, the multiple passes for resolving type names is done first, > using high-level type classes, before any LLVM IR is involved. The high > level classes are needed anyway since the LLVM type model does not capture > concepts such as const, up-casting, and other aspects of high-level types. > (Actually, I don't have discrete
2008 Sep 08
0
[LLVMdev] Problems when refining type
On Mon, Sep 8, 2008 at 2:45 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote: > LLVMTypeRef a = LLVMPointerType(LLVMOpaqueType(), 0); > LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); > LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; > LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); > > Can anyone explain what I'm doing wrong