search for: llvmtyperef

...interTypes map, which seems to cause problems. I sort of feel like it probably shouldn't be found because the opaque types should be distinct, but I also don't really understand how it ought to work, so maybe I'm way off base. ------------- #include "Core.h" int main() { LLVMTypeRef a = LLVMPointerType(LLVMOpaqueType(), 0); LLVMTypeHandleRef ha = LLVMCreateTypeHandle(a); LLVMTypeRef atypes[1] = { LLVMResolveTypeHandle(ha) }; LLVMRefineType(LLVMResolveTypeHandle(ha), LLVMStructType(atypes, 1, 0)); LLVMTypeRef b = LLVMPointerType(LLVMOpaqueType(), 0); // ass...

Hi (Gordon). There appears to be two wrapper functions for DerivedType::refineAbstractTypeTo() in llvm-c (Core.h, Core.cpp): void LLVMRefineAbstractType(LLVMTypeRef AbstractType, LLVMTypeRef ConcreteType){ DerivedType *Ty = unwrap<DerivedType>(AbstractType); Ty->refineAbstractTypeTo(unwrap(ConcreteType)); } void LLVMRefineType(LLVMTypeRef AbstractTy, LLVMTypeRef ConcreteTy) { unwrap<DerivedType>(AbstractTy)->refineAbstractTypeTo(unwrap...

...); Please use smallvector. +bool UnionType::isValidElementType(const Type *ElemTy) { + return !ElemTy->isVoidTy() && !ElemTy->isLabelTy() && + !ElemTy->isMetadataTy() && !isa<FunctionType>(ElemTy); +} Isn't there a better predicate somewhere? +LLVMTypeRef LLVMUnionTypeInContext(LLVMContextRef C, LLVMTypeRef *ElementTypes, + unsigned ElementCount) { + std::vector<const Type*> Tys; + for (LLVMTypeRef *I = ElementTypes, + indentation of unsigned and use smallvector. +/// ParseUnionType +/// TypeRec +/// ::= ...

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

...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], [lltype] > values may become > - * invalid; use [lltypehandle] to resolve this problem. See the > - * llvm::AbstractT...

--- 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:

...---------- Change this hex representation to test multiple scenarios. printf("[llvmPrintf# %s] Generating code from C program: \n", moduleName); LLVMModuleRef modCEx = LLVMModuleCreateWithNameInContext(moduleName, context); // "main" function type definition: LLVMTypeRef ppInt8 = LLVMPointerType(LLVMPointerType(LLVMInt8Type(), 0), 0); LLVMTypeRef vpMainFuncTypes[] = { LLVMInt32Type(), ppInt8 }; LLVMTypeRef rMainFuncType = LLVMFunctionType(LLVMInt32Type(), vpMainFuncTypes, 2, 0); LLVMValueRef vFnMain = LLVMAddFunction(modCEx, "main", rMainFuncT...

ping... On Thu, Jan 28, 2010 at 12:25 PM, Talin <viridia at gmail.com> wrote: > OK here's a new version of the patch - and the unions.ll test actually > passes :) > > On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On Jan 16, 2010, at 11:15 AM, Talin wrote: >> >> OK here's the patch for real this

...LLVMContextCreate(); LLVMModuleRef module; module = LLVMModuleCreateWithNameInContext("MyModule", llvm); //LLVMSetDataLayout(module, "i686-apple-darwin11"); <-- is needed? What is correct? LLVMSetTarget(module, "i686-apple-darwin11"); LLVMTypeRef int32 = LLVMInt32TypeInContext(llvm); LLVMTypeRef funcType; LLVMTypeRef threeInts[] = {int32, int32, int32}; funcType = LLVMFunctionType(int32, threeInts, 3, 0); LLVMValueRef func; func = LLVMAddFunction(module, "functionName", funcType); LLVMValueRef mP...

Okay after translating the headers to Delphi, i found more inconsistencies: > LLVMTypeRef LLVMFunctionType(LLVMTypeRef ReturnType, > LLVMTypeRef *ParamTypes, unsigned ParamCount, > LLVMBool IsVarArg); > In this case it is the other way around. 0 means False and anything else means true :/ (so it acts more like a "t...

Hi, The include file include/llvm-c/Core.h contains declarations such as "LLVMTypeRef LLVMInt1Type();", which raises the warning "function declaration isn't a prototype" when using them in .c files. Using "(void)" instead of "()" is the solution of course. Could someone please: sed -i~ 's/()/(void)/' Core.h [Sorry to be picky, but so...

...llvm = LLVMContextCreate(); LLVMModuleRef module; module = LLVMModuleCreateWithNameInContext("MyModule", llvm); //LLVMSetDataLayout(module, "i686-apple-darwin11"); <-- is needed? What is correct? LLVMSetTarget(module, "i686-apple-darwin11"); LLVMTypeRef int32 = LLVMInt32TypeInContext(llvm); LLVMTypeRef funcType; LLVMTypeRef threeInts[] = {int32, int32, int32}; funcType = LLVMFunctionType(int32, threeInts, 3, 0); LLVMValueRef func; func = LLVMAddFunction(module, "functionName", funcType); LLVMValueRef mParam =...

Of course, this is normal for C-APIs. But maybe change the name to LLVMResult to propagate the real use? I am not arguing about the results themself. They are standard. But the name is missguiding. As long as it's consistent i know that i have to write an extra record operator in Delphi to reflect this. 2016-09-12 11:11 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On

...Type *ElemTy) { > + return !ElemTy->isVoidTy() && !ElemTy->isLabelTy() && > + !ElemTy->isMetadataTy() && !isa<FunctionType>(ElemTy); > +} > > Isn't there a better predicate somewhere? > Apparently there is now. Done. > > +LLVMTypeRef LLVMUnionTypeInContext(LLVMContextRef C, LLVMTypeRef > *ElementTypes, > + unsigned ElementCount) { > + std::vector<const Type*> Tys; > + for (LLVMTypeRef *I = ElementTypes, > + > > indentation of unsigned and use smallvector. > > Done. &...

Hi all, consider the following function from Core.cpp in LLVM 9.0.0: LLVMValueRef LLVMBuildMalloc(LLVMBuilderRef B, LLVMTypeRef Ty, const char *Name) { Type* ITy = Type::getInt32Ty(unwrap(B)->GetInsertBlock()->getContext()); Constant* AllocSize = ConstantExpr::getSizeOf(unwrap(Ty)); AllocSize = ConstantExpr::getTruncOrBitCast(AllocSize, ITy); Instruction* Malloc = CallInst::CreateM...

...e wrapper C funtcion _w ## func. So when we use LLVMAddFunction methoed in python, it actually calls _wLLVMAddFunction. Then how is _wLLVMAddFunction defined? Also in *_core.c* file, there is such a statement that is related to LLVMAddFunction: *_wrap_objstrobj2obj(LLVMAddFunction, LLVMModuleRef, LLVMTypeRef, LLVMValueRef) * This macro is defined in wrap.h file: */** * Wrap LLVM functions of the type * outtype func(intype1 arg1, const char *arg2, intype3 arg3) */ #define _wrap_objstrobj2obj(func, intype1, intype3, outtype) \ static PyObject * \ _w ## func (P...

...y be a bit long. (Would LL be better?) LLVM seems fine to me, and the naming convention seems ok (using lowercase + underscores makes the name longer). I do find things like this slightly strange: /* Same as Module::addTypeName. */ int AddTypeNameToModule(LLVMModuleRef M, const char *Name, LLVMTypeRef Ty); I'd expect it to be named something like "LLVMModuleAddTypeName" or something, using NamespaceClassMethod uniformly. > Pointers are opaque, obviously. I find myself copying enums, which > is mildly scary. Copying the enums does seems scary. Is there any way around t...

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 her...

> The include file include/llvm-c/Core.h contains declarations > such as "LLVMTypeRef LLVMInt1Type();", which raises the > warning "function declaration isn't a prototype" when > using them in .c files. Can you please send a patch. See http://llvm.org/docs/DeveloperPolicy.html#patches Thanks, Duncan.

...r I run into issues when I try to get the argument types to the function. The basic gist of my code is as follows. (Note I snipped the error checking, but everything is returning OK): My understanding is that I must get a handle (LLVMValueRef) to the function and from that pull it's type as a LLVMTypeRef. This would be a 'function type', from which I can pull info about the return type and iterate the arguments, etc. At least, that's what I'm trying to do in my code: LLVMContextRef context = LLVMContextCreate(); LLVMMemoryBufferRef fileMemBuff; LLVMCreateMemoryBufferWit...