similar to: [LLVMdev] Tarjan+function_ptrs == trouble ? (fwd)

Test Cases: (attached) Iteration code: (...) typedef TarjanSCC_iterator<CallGraph*> MyTarjan; CallGraph& callGraph = getAnalysis<CallGraph>(); MyTarjan iter = tarj_begin(&callGraph); MyTarjan end = tarj_end(&callGraph); while(iter!=end) iter++; (...) if you take the time to print out the function each non-looping node iter traverses, it never reaches main...

Thanks, I've been through the documentation, and if I visit main, i think everything will turn out correctly... Printing out the Call graph reveals that main is calling this external node i think you are making reference to. Could this be the problem? Dave On Fri, 6 Dec 2002, Chris Lattner wrote: > > if you take the time to print out the function each non-looping node iter >

> if you take the time to print out the function each non-looping node iter > traverses, it never reaches main... Ok, first note that the CallGraph class does really stupid (but correct) things for function pointers, so you're not going to see anything remarkably nice here... Make sure to read the CallGraph.h comments to understand exactly what is going on. Despite that, I can verify

> 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? I'll need some more details before 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

​Hi all, I am using llvmlite for pyvex and I want the output of my code (which is written based on llvmlite) to be like pyvex. In pyvex, (https://github.com/angr/pyvex). Considering pyvex, I tried to implement the following statements in pyvex to llvmlite: for stmt in irsb.statements: if isinstance(stmt, pyvex.IRStmt.Store): print "ST%s(%s) = %s" % (self.endness[-2:].lower(),

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>

Hello, I'm wondering why only some global static variables are marked with __used__ attributes in llvm-gcc/gcc/crtstuff.c. GCC compiles 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]

Albert Graef wrote: > 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. > I use the fastcall convention all the time. LLVM-jitted code calling GCC-compile

I'm creating 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

LLVM, What do I pass into the DSG in order to access the globals vector of functions that a function pointer may be calling. The code: CallInst *calli = dynamic_cast<CallInst*>(*i); std::vector<GlobalValue*> funcVect = theGraph.getNodeForValue(calli->getCalledFunction()).getNode()->getGlobals(); Doesn't appear to work... getCalledFunction() returns 0 Dave On Fri, 6 Dec

On Wed, Jul 17, 2013 at 9:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > To maintain the semantics of ordinary function calls, the prefix data > must have a particular format. Specifically, it must begin with a > sequence of bytes which decode to a sequence of machine instructions, > valid for the module's target, which transfer control to the point >

As much as I like this idea for it's use in languages with type systems like Haskell and Scheme, this proposal would limit LLVM to non-Harvard architectures. That's generally a really small minority of all processors, but it would mean there could never be a clang-avr. An alternative you could use is, instead of using the function pointer as the variable where you are referring to a

Hi, I would like to propose that we introduce a mechanism in IR to allow arbitrary data to be stashed before a function body. The purpose of this would be to allow additional data about a function to be looked up via a function pointer. Two use cases come to mind: 1) We'd like to be able to use UBSan to check that the type of the function pointer of an indirect function call matches the