search for: func_ptr

...------------- next part -------------- #include <stdlib.h> #include <stdio.h> //#define WORKS int * a_global; int a_predicate = 1; int another_pred =0; int func_one() { return 1; } int func_two() { return 2; } int func_three() { return 3; } int main() { int (*func_ptr)(); if(a_predicate) func_ptr = func_one; else if(another_pred) func_ptr = func_two; else func_ptr = func_three; #ifdef WORKS return func_one(); #else return func_ptr(); #endif }

...t; int * a_global; > > int a_predicate = 1; > int another_pred =0; > > int func_one() > { > return 1; > } > > int func_two() > { > return 2; > } > > int func_three() > { > return 3; > } > > int main() > { > int (*func_ptr)(); > > if(a_predicate) > func_ptr = func_one; > else if(another_pred) > func_ptr = func_two; > else > func_ptr = func_three; > > #ifdef WORKS > return func_one(); > #else > return func_ptr(); > #endif > } >...

Dear LLVM, Recently I incorporated code into my project such that function pointers were supported, however it seems that the TarjanSCC_iterator no longer works on the call graph... main() is no longer reached while the function pointers are... I can provide code, but I have a feeling there is a simple fix... Has anyone gone through this? Thanks, Dave

...-------- Testcase ------------------------ #include <stdlib.h> #include <stdio.h> //#define WORKS int * a_global; int a_predicate = 1; int another_pred =0; int func_one() { return 1; } int func_two() { return 2; } int func_three() { return 3; } int main() { int (*func_ptr)(); if(a_predicate) func_ptr = func_one; else if(another_pred) func_ptr = func_two; else func_ptr = func_three; #ifdef WORKS return func_one(); #else return func_ptr(); #endif }

...machine = target.create_target_machine() backing_mod = llvm.parse_assembly("") engine = llvm.create_mcjit_compiler(backing_mod, target_machine) mod = llvm.parse_assembly( str( module ) ) mod.verify() engine.add_module(mod) engine.finalize_object() func_ptr = engine.get_function_address("read_instructions") c_fn_fib = CFUNCTYPE(c_int64, c_int64)(func_ptr) Having the above code, when running it, I am stopped with error:AttributeError: 'IMark' object has no attribute 'data' Can anyone help me in this way?Thank...

...mpiles crtstuff.c with -fno-toplevel-reorder option, which ensures that unused static globals are not removed during optimization. However, since LLVM does not support that option, I presume __used__ attribute is used instead. For example, __CTOR_LIST__[1] definition is changed as follows: STATIC func_ptr __CTOR_LIST__[1] /* LLVM LOCAL begin */ #ifdef __llvm__ __attribute__ ((__used__, aligned(sizeof(func_ptr)))) #else __attribute__ ((__unused__, aligned(sizeof(func_ptr)))) #endif /* LLVM LOCAL end */ = { (func_ptr) (-1) }; Note that __unused__ just suppresses the warning that __CTOR_LIST__ i...

Jeff Kuskin wrote: > Correct? If not, how do I call a LLVM JIT-generated fastcc function > from a function statically compiled by GCC? Well, you can always generate a little wrapper function with C calling convention which just calls the fastcc function. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at

...little wrapper function with C calling > convention which just calls the fastcc function. > I use the fastcall convention all the time. LLVM-jitted code calling GCC-compile code and vice-versa. This works for x86 (32 bit): void* llvm_jit_compile(); typedef __attribute__((fastcall)) int (*func_ptr)(int p1, int p2); int g(void) { func_ptr f = (func_ptr)llvm_jit_compile(); return f(1, 2); } Mark

...g a structure type which has a variable component. I'm not clear on the correct way to ensure the alignment of the variable part is correct and how to get the offset. For example, I have a wrapping structure format that looks like this: struct wrap: int32 ref_count PointerType(FunctionType) func_ptr T data Where 'T' is the desired extra data. I need to ensure that T is always at the same offset in this structure (thus I can't simply create a structure with all the elements). T will be used opaquely (a pointer passed to func_ptr as the first parameter, the function then casts it t...

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

On Thu, Dec 10, 2015 at 4:51 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/10/2015 04:29 PM, Xinliang David Li wrote: >> >> On Thu, Dec 10, 2015 at 4:00 PM, Philip Reames >> <listmail at philipreames.com> wrote: >>> >>> Given I didn't get any response to my original query, I chose not to >>> invest

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,

Hello, Is there any exist LLVM Target (backend) that support PC relative load and store? If so, what exactly is the instruction? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/c345ac5c/attachment.html>