search for: llvmgetparams

...index ~0U. Yes, that's what the documentation seems to say is the proper mode for indexing the return parameter, but when I set an attribute on the parameter with index zero, it gets applied to the first function argument and not the return parameter. I believe the reason for this to be that LLVMGetParams() [and its cognates] all use Function::arg_iterator, which begins with the first function *argument* parameter and not the return parameter. The index argument to LLVMGetParams() is actually incremented by one when it's mapped to the index used for the Function::AttributeList member. There ar...

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

...t; Yes, that's what the documentation seems to say is the proper mode for indexing the return parameter, but when I set an attribute on the parameter with index zero, it gets applied to the first function argument and not the return parameter. > > I believe the reason for this to be that LLVMGetParams() [and its cognates] all use Function::arg_iterator, which begins with the first function *argument* parameter and not the return parameter. The index argument to LLVMGetParams() is actually incremented by one when it's mapped to the index used for the Function::AttributeList member. There ar...

everyone-- Is it my imagination, or is there no way in LLVM 2.8 (or current trunk) to use the facilities defined in <llvm-c/Core.h> to get or set the optional return parameter attribute on a function value? All the functions in the "Operations on parameters" parameters section actually seem to work only on the function arguments and not the return parameter. Is this intentional?

Hi James, > Is it my imagination, or is there no way in LLVM 2.8 (or current trunk) to use the facilities defined in<llvm-c/Core.h> to get or set the optional return parameter attribute on a function value? > > All the functions in the "Operations on parameters" parameters section actually seem to work only on the function arguments and not the return parameter. Is this

On Sep 7, 2010, at 8:03 AM, F van der Meeren wrote: > Hello, > > I have a question, what is wrong with the following code? > > declare void @llvm.memcpy.p0i64.p0i64.i8(i64*, i64*, i8, i32, i1) nounwind > > ... > > call void @llvm.memcpy.p0i64.p0i64.i8(i64* %19, i64* %21, i8 %17, i32 0, i1 false) > > ... > > > According to the compiler this is the

I have created the function prototype with the following code: const uintmax_t methodNameSize = 1024; const char methodNameTemplate[] = "llvm.memcpy.p0i%llu.p0i%llu.i%llu"; char methodName[methodNameSize]; // Create the methodName. memset(methodName, 0, methodNameSize); sprintf(methodName, methodNameTemplate, dstSize, srcSize, lengthSize); // Search for the

Hi, I'm attempting to use MCJIT with the C interface with llvm-3.9.0, and it doesn't seem to work. This code is derived from Paul Smith's example code: int main(int argc, char const* argv[]) { LLVMModuleRef mod = LLVMModuleCreateWithName("my_module"); LLVMTypeRef param_types[] = {LLVMInt32Type(), LLVMInt32Type()}; LLVMTypeRef ret_type =

Hello, I have a question, what is wrong with the following code? declare void @llvm.memcpy.p0i64.p0i64.i8(i64*, i64*, i8, i32, i1) nounwind ... call void @llvm.memcpy.p0i64.p0i64.i8(i64* %19, i64* %21, i8 %17, i32 0, i1 false) ... According to the compiler this is the error, but I seem to miss where exactly my fault is. Intrinsic prototype has incorrect number of arguments! void (i64*,

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

Hi, revision 111418 binding/ocaml/llvm/llvm_ocaml.c /* llvalue -> int -> llvalue */ CAMLprim value llvm_params(LLVMValueRef Fn, value Index) { value Params = alloc(LLVMCountParams(Fn), 0); LLVMGetParams(Fn, (LLVMValueRef *) Op_val(Params)); return Params; } does not match the interface at binding/ocaml/llvm/llvm.ml external params : llvalue -> llvalue array = "llvm_params" It should be /* llvalue -> llvalue */ CAMLprim value llvm_params(LLVMValueRef Fn) { ... This cannot be...

mingw, llvm 2.6 (buid with llvm-gcc) Example source code: http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html I change LLVMCreateJITCompiler(&engine, provider, &error); to LLVMCreateJITCompiler(&engine, provider, 3, &error); $ llvm-gcc `llvm-config --cflags` -c fac.c $ g++ `llvm-config --libs --cflags --ldflags core analysis executionengine jit

Attached is what I got thus far. What I'm struggling with is proper integration in build system. What is in there is just wild guesses from my side, both on autoconf and cmake variants. It would be great if someone with proper knowledge of the buildsystems could have a look. Also I'm not sure how to properly handle compilation on msvc - clearly "-std=c11 -Wstrict-prototypes" is