search for: optimiziers

Hi everybody, I need like to port the flac encoding and decoding algorithm on the VisualDSP platform. Do you know if it's already existing a flac version for that? I'm trying to estimate the computational cost of FLAClib on blackfin. Do you know some profiling information for blackfin? I saw the assembler code for CPU dependent optimiziations. Is there something similar for blackfin? I

I am having trouble understanding the relationship between LLVM identifiers, stack (alloca) and variables. In particular, when I need to create a variable, what should I use? For instance, consider the following C-like language snippet: int f() { int i = rand(); if(i > 5) i = 1; return i; } Ignoring optimizations, what should I use to represent 'i'? Online demo gives the following

...> The frontend can't know anything about the optimization passes that LLVM > will perform on the function. > Sure. And I think the way to go is to remove the llvm.gcroot intrinsic (and the hackish way it currently works: right now, because we take the address of the alloca, the LLVM optimiziers won't try to optimize an alloca that may escape through the llvm.gcroot function call). By having an address space for GC roots, optimizers don't need to care about anything. After the optimizers and the register allocator, a final LLVM pass should compute the root lists of all sync points....

On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: >> >> Thinking about it even more, here's a short summary of what I would >> propose: >> >> - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage

...;t know anything about the optimization passes that LLVM >> will perform on the function. >> > > Sure. And I think the way to go is to remove the llvm.gcroot intrinsic (and > the hackish way it currently works: right now, because we take the address > of the alloca, the LLVM optimiziers won't try to optimize an alloca that may > escape through the llvm.gcroot function call). By having an address space > for GC roots, optimizers don't need to care about anything. After the > optimizers and the register allocator, a final LLVM pass should compute the > root lists...

Hi Again, I'm a little confused regarding what is the exact Orc's functions I should use in order to save the functions code in a code cache so it could be later replaced with different versions of it and I appreciate your help. Just a reminder I want to dynamically recompile the program based on profile collected at the run-time. I would like to start executing the program from the