search for: function_typ

...k it might be because my declaration and use of sprintf is wrong. I notice llvm-gcc produces declarations containing "..." like: declare int %printf(sbyte*, ...) but I'm not sure how to do this so I've used: let sprintf = declare_function "sprintf" (function_type (pointer_type i8_type) [| pointer_type i8_type; pointer_type i8_type; i32_type |]) m in which gives: declare i8* @sprintf(i8*, i8*, i32) What is the correct way to do this? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Here's my translation of the Fibonacci example into OCaml: open Printf open Llvm let build_fib m = let fibf = define_function "fib" (function_type i32_type [| i32_type |]) m in let bb = builder_at_end (entry_block fibf) in let one = const_int i32_type 1 and two = const_int i32_type 2 in let argx = param fibf 0 in set_value_name "AnArg" argx; let retbb = append_block "return" fibf in let retb = builde...

On Monday 26 November 2007 00:40, Gordon Henriksen wrote: > The type you want is: > > let sp = pointer_type i8_type in > var_arg_function_type sp [| sp; sp |] Awesome stuff. Here is my most elegant Fibonacci example in OCaml so far: open Llvm let ( |> ) x f = f x let int n = const_int i32_type n let return b x = build_ret x b |> ignore let build_fib m = let ty = function_type i32_type [| i32_type |] in let fibf = define_...

..."jithelloworld" in (* @greeting = global [14 x i8] c"Hello, world!\00" *) let greeting = define_global "greeting" (const_stringz "Hello, world!") m in (* declare i32 @puts(i8* ) *) let puts = declare_function "puts" (function_type i32_type [| pointer_type i8_type |]) m in (* define i32 @main() { entry: *) let main = define_function "main" (function_type i32_type [| |]) m in let at_entry = builder_at_end (entry_block main) in (* %tmp = getelementptr [14 x i8]* @greeting, i32 0, i32...

...ht be because my declaration and use of sprintf is wrong. > > I notice llvm-gcc produces declarations containing "..." like: > > declare int %printf(sbyte*, ...) > > What is the correct way to do this? The type you want is: let sp = pointer_type i8_type in var_arg_function_type sp [| sp; sp |] — Gordon

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

...k; f, f_blk] "join" (bb state) in phi, state | Apply(f, arg) -> let f, state = expr state f in let arg, state = expr state arg in build_call f [|arg|] "apply" (bb state), state let defn m vars = function | LetRec(f, arg, body) -> let ty = function_type i32_type [| i32_type |] in let fn = define_function f ty m in let vars' = (arg, param fn 0) :: (f, fn) :: vars in let body, state = expr { fn = fn; blk = entry_block fn; vars = vars' } body in build_ret body (bb state) |> ignore; (f, fn) :: vars let int n...

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

...m] AGP at 0xe0000000 256MB info: [drm] Initialized radeon 1.25.0 20060524 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [ITHREAD] pccard1: <unknown card> (manufacturer=0x0156, product=0x0003, function_type=6) at function 0 pccard1: CIS info: Agere Systems, Wireless PC Card Model 0111, , ----- ----- uname -a FreeBSD vallhala.invalidnivozik.cz 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #5: Thu Oct 9 17:44:43 CEST 2008 build@vallhala.invalidnivozik.cz:/usr/obj/usr/src/sys/GENERIC i386 ----- --...

Jon, On 2007-11-24, at 21:58, Jon Harrop wrote: > I just took another look at the LLVM project and it has come along > in leaps and bounds since I last looked. I've been working through > the (awesome!) tutorial and am now really hyped about the project. Excellent! > I am particularly interested in using LLVM to write compilers for > OCaml-like languages in OCaml-like

I have a Function* to a function that has a signature like: void foo(double*, double*); I need to write the address of this function into a global variable initializer (really, into the initializer of a particular structure field). The structure field type is void*, and must be. Because of type constraints, doing something like: Function* foo = ...; std::vector<const Type*> fields; ...

...765 #4 0x084d05e6 in rest_of_decl_compilation (decl=0xb7b9d618, top_level=1, at_end=0) at ../../2006-03-14-llvm-gcc-4/gcc/passes.c:204 Printing decl in frame 2 gives: (gdb) call debug_tree(decl) <function_decl 0xb7b9d618 _X_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv type <function_type 0xb7ab7e88 type <void_type 0xb7ab5b40 void sizes-gimplified type_6 VOID align 8 symtab 146744576 alias set -1 pointer_to_this <pointer_type 0xb7ab5bb8>> type_6 QI size <integer_cst 0xb7aa139c constant invariant 8> unit size...

Hi! I just took another look at the LLVM project and it has come along in leaps and bounds since I last looked. I've been working through the (awesome!) tutorial and am now really hyped about the project. I am particularly interested in using LLVM to write compilers for OCaml-like languages in OCaml-like languages. This requires some core functionality that would be generically useful:

Hi - I have a dataframe of (x,y) values. I'd like to fit an exponential curve to the data for further statistical analysis (pretty much the same functionality provided by Excel's LOGEST worksheet array function). Can someone point me to the (set of) functions/ package that is best suited to provide this functionality? Admittedly, I am a novice in the use of R statistical functions,

...= create_module filename in (* @greeting = global [14 x i8] c"Hello, world!\00" *) let greeting = define_global "greeting" (const_string "Hello, world!\000") m in (* declare i32 @puts(i8* ) *) let puts = declare_function "puts" (function_type i32_type [|pointer_type i8_type|]) m in (* define i32 @main() { entry: *) let main = define_function "main" (function_type i32_type [| |]) m in let at_entry = builder_at_end (entry_block main) in (* %tmp = getelementptr [14 x i8]* @greeting, i32 0, i32 0 *) let zero =...

Evan Cheng wrote: > Hi, > > Here is the follow on patch for this problem. Please apply this from > the top of the tree and rebuild. With the patch from Chris and then the patch from you combined, the previous error disappeared, but I get another error, reduced to this: ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro -auxbase-strip libgcc/./_clz.o -g -O2

Dear all, I have just created a couple of differential reviews to enable the vectorisation of loops that have function calls to routines marked with “#pragma omp declare simd”. They can be (re)viewed here: * https://reviews.llvm.org/D27249 * https://reviews.llvm.org/D27250 The current implementation allows the loop vectorizer to generate vector code for source file as: #pragma omp declare

...nique function it could choose from the list the TLI provides. This is not the same on Intel, for example when this code generates vector names for AVX and AVX2. The register width for these architecture extensions are the same, so all the TLI has is a mapping between scalar name and (vectro_name, function_type) who's two elements differ only in the vector_name string. This breaks the target independence of the vectorizer, as it would require it to parse the vector_name to be able to choose between the AVX or the AVX2 implementation. Now, to make this work one should have to encode the SSE/SSE2/AVX...

...uld choose from the list the TLI provides. > >This is not the same on Intel, for example when this code generates >vector names for AVX and AVX2. The register width for these architecture >extensions are the same, so all the TLI has is a mapping between scalar >name and (vectro_name, function_type) who's two elements differ only in >the vector_name string. > >This breaks the target independence of the vectorizer, as it would >require it to parse the vector_name to be able to choose between the AVX >or the AVX2 implementation. > >Now, to make this work one should hav...

...s += " "; + s += "["; + if (dimension.is_string()) + s += dimension.as_string(); + else if (dimension.is_node()) + dimension.as_node()->print(s); + s += "]"; + base->print_right(s); + } +}; + +class function_type final : public type { + unsigned nparams; + node** params; + node* ret; +public: + function_type(node* ret, unsigned nparams, node** params) + : nparams(nparams), params(params), ret(ret) { + has_function(true); + } + + // int (*f)(float)[10] + // here, ret =...