search for: cloneandprunefunctioninto

...ill go wrong if I > do that? Is there a better way, or an option that doesn't involve > writing new code? Hi Jeffrey, Does this need to be an actual pass? You can just call the InlineFunction API to inline individual call sites as needed, check out llvm/Transforms/Utils/Cloning.h. CloneAndPruneFunctionInto is a particularly useful function if you're doing argument specialization, because it is very efficient at handling this (better than inlining a bunch of code and then deleting it as dead later). -Chris

In Unladen Swallow we (intend to) compile each function as we determine it's hot. To "compile" a function means to translate it from CPython bytecode to LLVM IR, optimize the IR using a FunctionPassManager, and JIT the IR to machine code. We'd like to include inlining among our optimizations. Currently the Inliner is a CallGraphSCCPass, which can only be run by the

Hello All, I have some data tied to the basic blocks in a function, and after inlining that function, I'd like to recover that data in the inlined version. Is there some way to match up the inlined version of the function with the original basic blocks? Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL:

...in(), OldFE = Old.arg_end(), NewFI = New->arg_begin(); OldFI != OldFE; ++OldFI, ++NewFI) { Argument &OldA = *OldFI; Argument &NewA = *NewFI; NewA.setName(OldA.getName()); VMap[&OldA] = &NewA; } SmallVector<ReturnInst *, 16> Returns; CloneAndPruneFunctionInto(New, &Old, VMap, true, Returns); return New; } bool FunctionDuplication::runOnModule(Module &M) { DataLayout const &DL = M.getDataLayout(); bool Modified = false; std::vector<Function *> Functions; for (auto &Fn : M.functions()) { Functions.push_back(&Fn);...

...t; with the specific "childtype_do_foo()" call when we know the type of the > child? Will you know the prototype of the function call in advance? If so, you can do something really simple where you write the C functions with a function pointer parameter. Then at run-time, use llvm::CloneAndPruneFunctionInto to produce the specialized function by giving it a valuemap that maps the Argument* for the fptr to the concrete Function* you want it to call. If you don't know the type of the call you intend to place, the question becomes "why not?" What arguments were you planning to pass it,...

...xt); + + SmallVector<Value *, 4> MDVs; + MDVs.push_back(InsnMD->getElement(0)); // Line + MDVs.push_back(InsnMD->getElement(1)); // Col + MDVs.push_back(InsnMD->getElement(2)); // Scope + MDVs.push_back(NewLoc); + return MDNode::get(Context, MDVs.data(), MDVs.size()); +} + /// CloneAndPruneFunctionInto - This works exactly like CloneFunctionInto, /// except that it does some simple constant prop and DCE on the fly. The /// effect of this is to copy significantly less code in cases where (for @@ -361,7 +383,8 @@ SmallVectorImpl<ReturnInst*> &Retur...

...OldFI != OldFE; ++OldFI, ++NewFI) { >> Argument &OldA = *OldFI; >> Argument &NewA = *NewFI; >> NewA.setName(OldA.getName()); >> VMap[&OldA] = &NewA; >> } >> >> SmallVector<ReturnInst *, 16> Returns; >> CloneAndPruneFunctionInto(New, &Old, VMap, true, Returns); >> >> return New; >> } >> >> bool FunctionDuplication::runOnModule(Module &M) { >> DataLayout const &DL = M.getDataLayout(); >> bool Modified = false; >> >> std::vector<Function *> Funct...

...t;childtype_do_foo()" call when we know the type of the >> child? > > Will you know the prototype of the function call in advance? If so, you > can do something really simple where you write the C functions with a > function pointer parameter. Then at run-time, use > llvm::CloneAndPruneFunctionInto to produce the specialized function by > giving it a valuemap that maps the Argument* for the fptr to the > concrete Function* you want it to call. Great! I wasn't aware of that, so that's really helpful. > If you don't know the type of the call you intend to place, the ques...

Devang Patel wrote: > Hi John, > > On Wed, Nov 4, 2009 at 12:04 PM, John Criswell <criswell at uiuc.edu> wrote: > >> Dear All, >> >> 1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip >> away debug information when such information interferes with >> optimization. Is this correct, >> > > Yes. > >

...ristics for identifying regions to outline need to be. One thing that I’ve discussed with a co-worker but haven’t explored in my implementation yet is the possibility of using CodeExtractor to do the outlining rather than basing it on the CloneFunction stuff. My current implementation is based on CloneAndPruneFunctionInto as you suggested, but I wondered if CodeExtractor might not be a better starting point. What do you think? Also, at the moment I’m more or less ignoring the frame variable issue. My ValueMaterializer is just creating new allocas with the name I want. I think that will be easy enough to patch up...

...ase(target,control,-PI/(2*pow(2,j))); } int main() { .. int b = 3; for (int j=1; j < b; j++) ControlledRotationPiMinus(target, control, j); .. } Here is what I am doing: The function ControlledRotationPiMinus is called twice in main(), with values of j=1,2. I do procedure cloning (using CloneAndPruneFunctionInto) resulting in 2 copies of this function with the values of j set to a fixed number (1 and 2). However the mathematical expression inside these copies fails to resolve to a fixed number and propagate. So for the first copy, with j=1, I get the following llvm code: LLVM code: ========= define void...

Hi, Would LLVM be adapted to express and do some kind of function "partial evaluation", like having a function of 2 arguments, and when a value of one of the 2 parameter is known, the function could be specialized to produce as result a more efficient new function that would take one 1 parameter. I was told that the "ReplaceAllUsesWith" operation could be possibly

...onst Value*, Value*> ValueMap object. > Populate it > with mappings from the generic function's arguments to either > the new > functions arguments (if they are not specialized) or the > constants you > want to specialize the argument to. > 4. Call the CloneAndPruneFunctionInto function > (llvm/Transforms/Utils/Cloning.h) passing in the new empty > (destination) function, the generic "source" function, and your > value > map. > 5. Run any other optimizations that you want over the new function. > > -Chris > > -- > htt...

Hi, we have two modules, one that we basically use as a library in which we store a lot of simple function calls, the other is small program generated at run-time. Whenever a function call for to one of the builtin functions is being called we use CloneFunction to clone the instruction from the library module and insert it in the generated module. The problem is for example when we have

Using C++ code, I would like to generate code at run-time (the same way .NET code can use dynamic methods or compiled expressions) in order to obtain very high performance code (to read binary data records whose formats are only known at run-time.) I need to target x86 (Win32) and ARM (WinCE). Can LLVM be used for this purpose, or would something else work better? Are there any open-source

...ock intrinsics can probably be built in isolation from the outlining. We can probably make `get_capture_block` work with the result of `@llvm.frameaddress(i32 0)`. The inliner also has to be taught to avoid inlining functions that set up a capture block. Doing outlining will be similar what `llvm::CloneAndPruneFunctionInto` does, except it will start at the landing pad instead of the entry block. Instead of mapping from parameters to arguments, the outliner would map the selector to a constant and propagate that value forwards, pruning conditional branches as it goes. The `resume` instruction would end outlining and...

...in(); j != f.arg_end(); ++j) { Argument* arg = j; Value* val; if (arg->getNameStr() == "n") { val = ConstantInt::get(Type::getInt32Ty(context), 3); valueMap[arg] = val; } } SmallVector<ReturnInst*, 8> returns; CloneAndPruneFunctionInto(specFunc, &f, valueMap, false, returns); m.getFunctionList().push_back(specFunc); } #include "llvm/Pass.h" #include "llvm/Function.h" #include "llvm/Module.h" #include "llvm/LLVMContext.h" #include "../specFunc/specializeFunc.h" using...

...ock intrinsics can probably be built in isolation from the outlining. We can probably make `get_capture_block` work with the result of `@llvm.frameaddress(i32 0)`. The inliner also has to be taught to avoid inlining functions that set up a capture block. Doing outlining will be similar what `llvm::CloneAndPruneFunctionInto` does, except it will start at the landing pad instead of the entry block. Instead of mapping from parameters to arguments, the outliner would map the selector to a constant and propagate that value forwards, pruning conditional branches as it goes. The `resume` instruction would end outlining and...

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

> We should also think about how to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once