search for: curtisfaith

On Fri, May 28, 2010 at 8:35 AM, Curtis Faith <curtis at curtisfaith.com> wrote: > Finally, I want to look at the machine code to see if perhaps this sort of > thing is handled by the optimization passes during machine code emission but > I can't figure out how to easily print out the machine code. Is there an > easy way to add a createMachineFunc...

On Tue, Jun 15, 2010 at 8:49 PM, Curtis Faith <curtis at curtisfaith.com> wrote: > It strikes me that with LLVM it ought to be possible to convert the variables to constants as part of an optimization pass that is run just before starting a simulation, or perhaps with a custom pass that I'll have to write myself. After the variables are converted to consta...

You should be able to use the second alternative that Nick proposed: cast<PointerType*>(pointer_value->getType())->getElementType() Reid On Fri, May 28, 2010 at 9:37 AM, Curtis Faith <curtis at curtisfaith.com> wrote: > Thanks Nick, > Unfortunately, that is indeed what I asked for but not what I really am > looking for. > My naive approach is to store symbol table entries as Value* objects so I > can allocate global variables and alloca variables and place them into the > symbol...

I'm working on the implementation of a high-performance financial trading simulation system. The simulations are CPU bound so faster is always better. I'm trying to determine the optimal architecture. So far, I'm very pleased with LLVM. I've been able to get our Basic-flavor scripting language for defining the simulation rules to perform at the equivalent of code that was written

Thanks Nick, Unfortunately, that is indeed what I asked for but not what I really am looking for. My naive approach is to store symbol table entries as Value* objects so I can allocate global variables and alloca variables and place them into the symbol table and the rest of the code didn't need to know which kind they were, in general. Loads and Stores of these types (as well as other

I concur. I've run into this exact assert at least 10 different times in the last two weeks since I started with LLVM as I'm learning the particulars of the typing system for function calls in particular. It would be nice if it would tell you what expected signature was, what the value of i was so you know which parameter went wrong, and what the actual type passed in was, as well as what

I just added support for arrays to the front-end for a trading-specific DSL that I'm implementing using LLVM and ran into a minor bump. Internally, I have been treating variables the same whether they end up being GlobalVariables or stack variables allocated with Alloca. I store the Value* I get from CreateAlloca or the Value* I get when I create a new GlobalVariable into my symbol table when

I have some LLVM IR after the optimization passes defined in createStandardModulePasses with the optimization level set to 3. It contains what appears to me to be an easily optimizable branch statement. In particular, note in the code below that at the end of the "loop" BasicBlock that there is a conditional branch where in the false case, it branches to the label

...ople deploy LLVM with the asserts disabled because they make the code ~10x slower. For unladen swallow, I tend to run our regression tests with asserts off so they finish faster, and if it crashes, I might go back and turn them on. Reid On Fri, Jun 18, 2010 at 6:33 AM, Curtis Faith <curtis at curtisfaith.com> wrote: > I'm trying to figure out the best way to handle signals raised during the > execution of LLVM's optimization passes or the JIT'ing of code prior to > running it. > In particular, LLVM throws unix signals instead of C++ exceptions while the > header ErrorH...

When for example some call is wrong error message always looks like this: Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file /tmp/llvm-svn/llvm/lib/VMCore/Instructions.cpp, line 247. I believe assert() statements should better be replaced with more

I'm trying to figure out the best way to handle signals raised during the execution of LLVM's optimization passes or the JIT'ing of code prior to running it. In particular, LLVM throws unix signals instead of C++ exceptions while the header ErrorHandling.h contains the following warning (the last paragraph in particular): /// llvm_instal_error_handler - Installs a new error handler

Is there a recommended way to retrieve the original type from an AllocaInst object? For example, I am creating alloca instructions using the IRBuilder interface like: alloca = builder.CreateAlloca( Type::getDoubleTy( context ), 0, variableName.c_str() ); and I place the alloca into a symbol table. Later when I am generating instructions for an assignment operation, I want to check the type of