search for: genericvalues

Hi all, I've been quiet for a while, but I'm liable to be less so now that I'm starting on porting our model checker from LLVM 1.8 to 2.0. One thing that is puzzling me somewhat are the changes made to the GenericValue union, which is now a struct. I haven't found any mention of this on the llvm site or in the archives, so it may be that I am the only one who cares about it

I'm trying to turn some GenericValues into Constants in the interpreter using code like this, in a switch statement: case Type::IntTyID: SI = ConstantSInt::get(FB->getType(), ArgVals[i].IntVal); params.push_back(UI); UI->dump(); //for testing break; FB is a Function::ArgumentListType::iterat...

Hi Sarah, On Tue, 2007-07-17 at 10:05 -0700, Sarah Thompson wrote: > Hi all, > > I've been quiet for a while, but I'm liable to be less so now that I'm > starting on porting our model checker from LLVM 1.8 to 2.0. We missed you! :) > One thing > that is puzzling me somewhat are the changes made to the GenericValue > union, which is now a struct. I

Reid Spencer wrote: > Hi Sarah, > > On Tue, 2007-07-17 at 10:05 -0700, Sarah Thompson wrote: > >> Hi all, >> >> I've been quiet for a while, but I'm liable to be less so now that I'm >> starting on porting our model checker from LLVM 1.8 to 2.0. >> > > We missed you! :) > > Yes, apologies again for not making the

Chris Lattner wrote: > On Tue, 17 Jul 2007, Sarah Thompson wrote: > > >> Do I understand correctly that there is nothing that the current gcc >> front end generates that wouldn't fit an old-style GenericValue? I'm >> wondering if this might be an interim approach that would avoid me >> needing to rewrite huge amounts of code, and since we're not

On Tue, 17 Jul 2007, Sarah Thompson wrote: > Do I understand correctly that there is nothing that the current gcc > front end generates that wouldn't fit an old-style GenericValue? I'm > wondering if this might be an interim approach that would avoid me > needing to rewrite huge amounts of code, and since we're not likely to > be supporting anything other than C and C++

...JIT'd code, e.g. by iterating over inputs inside the JIT instead of outside. If you want to improve performance of the GenericValue-based interface, I'd suggest trying to minimize the number and overhead of allocations in your Ocaml code, then look at the bindings themselves: - If GenericValues can't be reused, add bindings to allow mutating them. Reuse the same 'n' instances for each call into JIT code. Yucky imperative data structures to the rescue. - Write bindings for a heap-allocated GenericValue[] and wrap that in a custom block instead of heap-allocating each Gen...

Sorry I forgot to add code that I use to run code: /* Executes the AST by running the main function */ GenericValue CodeGenContext::runCode() { std::cout << "Running code...\n"; ExecutionEngine *ee = EngineBuilder(module).create(); vector<GenericValue> noargs; GenericValue v = ee->runFunction(mainFunction, noargs); std::cout << "Code was run.\n"; return v;

The blog post I linked to implied that adding a symbol in the form lle_X_FUNCTIONNAME would allow you to call a function called FUNCTIONNAME. Is this not the case? On Thu, Aug 19, 2010 at 6:46 PM, <o.j.sivart at gmail.com> wrote: > You are adding the symbol as "lle_X_create_number_object" yet your error > message implies you have tried to lookup and use

Sarah Thompson wrote: > Chris Lattner wrote: > >> On Tue, 17 Jul 2007, Sarah Thompson wrote: >> >> >> >>> Do I understand correctly that there is nothing that the current gcc >>> front end generates that wouldn't fit an old-style GenericValue? I'm >>> wondering if this might be an interim approach that would avoid me

Is there documentation somewhere on how to call external functions from llvm? The only guide I found was this: http://www.gearleaf.com/blog/post/44, and it doesn't seem to be working for me. I have a function: llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const std::vector<llvm::GenericValue>& args) { llvm_object_structure* result = new

Valery, Attached are three files: "valery.cpp" which contains your original, "reid.cpp" which contains corrections to most of the FIXME items and "diffs" which shows the differences between them. The differences should be instructive on what to do. You were really, really close .. just a few details changing. The code in "reid.cpp" compiles but I

On Mon, 9 Aug 2004, Reid Spencer wrote: > Attached are three files: "valery.cpp" which contains your original, "reid.cpp" > which contains corrections to most of the FIXME items and "diffs" which shows > the differences between them. The differences should be instructive on what to > do. You were really, really close .. just a few details changing. The

Hi all, I am facing new problem with lli now. I am having a sample code in which I am doing malloc for two variables. If I compile the code with normal gcc the program runs without any warning of any sorts. If I compile the program to convert it into a bytecode file and then run it through lli it segfaults and the program aborts. This is the stack trace after execution. lli((anonymous

I'm having another play with LLVM using the OCaml bindings for a forthcoming OCaml Journal article and I have a couple of remarks: Firstly, I noticed that the execute engine is very slow, taking milliseconds to call a JIT compiled function. Is this an inherent overhead or am I calling it incorrectly or is this something that can be optimized in the OCaml bindings? Secondly, I happened to

Hi, My application generates some LLVM assembly code which I then convert to IR code using ParseAssemblyString. If I have the following LLVM assembly code: define double @test() { ret double 1.230000e+02 } then, using ExecutionEngine::runFunction, I get a GenericValue return value which DoubleVal property is indeed equal to 123. So, all is fine there. However, if I have the

Hi all, I'm trying to print to screen the value read by the fread function. I'm at the point where source refers to the GetElementPtrInst ( pointer to the buffer where fread stored the data - %5 in my case ) and the fread() has been already called. I thought the correct approach to achieve what I need was: ExecutionContext& SF = ECStack.back(); GenericValue SRC =

On Jan 8, 2013, at 8:09 , Manuele Conti <manuele.conti at sirius-es.it> wrote: > Sorry I forgot to add code that I use to run code: > /* Executes the AST by running the main function */ > GenericValue CodeGenContext::runCode() { > std::cout << "Running code...\n"; > ExecutionEngine *ee = EngineBuilder(module).create(); > < > div

Hi, I am trying to run an LLVM analysis on a C++ program that calls qsort(), using the LLVM interpreter (lli --force-interpreter). The code is the qsort_large.c file in the MiBench benchmark suite. If I comment the qsort() call, the execution works fine. If I uncomment the qsort() call, I run into a segmentation fault error as follows: 0  lli             0x0000000000d35c6f 1  lli        

Hi, I am trying to run an LLVM analysis on a C++ program that calls qsort(), using the LLVM interpreter (lli --force-interpreter). The code is the qsort_large.c file in the MiBench benchmark suite. If I comment the qsort() call, the execution works fine. If I uncomment the qsort() call, I run into a segmentation fault error as follows: 0 lli 0x0000000000d35c6f 1 lli