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