search for: takenam

...body of the old one. Gabriel: look at Function::getBasicBlockList() and iplist<>::splice(iterator, iplist). Something like Function *NewF = Function::Create(NewFnType, OldF->getLinkage()); NewF->getBasicBlockList().splice(NewF->begin(), OldF->getBasicBlockList()); NewF->takeName(OldF); OldF->eraseFromParent(); is probably what you're looking for. (Note: completely untested)

...FunctionType::get(FTy->getReturnType(), Params, false); // Create the new function body and insert it into the module... Function *NF = Function::Create(NFTy, Fn->getLinkage()); NF->copyAttributesFrom(Fn); Fn->getParent()->getFunctionList().insert(Fn, NF); NF->takeName(Fn); for (Function::arg_iterator AI=F.arg_begin(), AE=F.arg_end(), NAI=NF->arg_begin(); AI != AE; ++AI, ++NAI) { NAI->takeName(AI); } // Since we have now create the new function, splice the body of the old // function right into the new function, leaving t...

Hi Stepan, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller is MergeFunctions, and I don't see any debug info tests for this so I'm wondering what /should/ happen here. In the case where the functions are internal I'm not sure there's anything we ca...

...;op_end()); callargs.insert(callargs.begin(), ConstantInt::get(Type::getInt32Ty(context), call->getNumArgOperands())); callargs.insert(callargs.begin(), callee->getName()); CallInst* newcall = CallInst::Create(launch, callargs, "", call); newcall->takeName(call); newcall->setCallingConv(call->getCallingConv()); newcall->setAttributes(call->getAttributes()); newcall->setDebugLoc(call->getDebugLoc()); call->replaceAllUsesWith(newcall); found = true; break; } The line callargs.insert(callarg...

...ion::getBasicBlockList() and >> iplist<>::splice(iterator, iplist). Something like >>   Function *NewF = Function::Create(NewFnType, OldF->getLinkage()); >>   NewF->getBasicBlockList().splice(NewF->begin(), >> OldF->getBasicBlockList()); >>   NewF->takeName(OldF); >>   OldF->eraseFromParent(); >> is probably what you're looking for. >> (Note: completely untested) And I did put a disclaimer about correctness :). Reading MakeFunctionClone() though, I do see some other things that I missed: * A Module* argument to Function::C...

...for n = 0, 1, ... , Add->getNumOperands()). A few other "parameters" like nuw/nsw/exact can be accessed as Add->hasNoUnsignedWrap()/setHasNoUnsignedWrap() and friends. Var name: Add->getName() / Add->setName(). Can efficiently be transfered to the new instruction with Sub->takeName(Add). The number is automatically assigned if it doesn't have a name. I'm not sure if there's an easy way to determine it other than printing it to a (string)stream and parsing the result. The type is usually automatically determined from the operands, but can be accessed as Add->g...

Hi Peter, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller is the DataFlowSanitizer, and I don't see any debug info tests for this so I'm wondering what /should/ happen here. Is DFSan+DebugInfo something that matters? I assume so. It looks like DFSan is c...

...Gabriel: look at Function::getBasicBlockList() and > iplist<>::splice(iterator, iplist). Something like > Function *NewF = Function::Create(NewFnType, OldF->getLinkage()); > NewF->getBasicBlockList().splice(NewF->begin(), OldF->getBasicBlockList()); > NewF->takeName(OldF); > OldF->eraseFromParent(); > is probably what you're looking for. > (Note: completely untested) -- John T.

...FunctionType::get(FTy->getReturnType(), Params, false); // Create the new function body and insert it into the module... Function *NF = Function::Create(NFTy, Fn->getLinkage()); NF->copyAttributesFrom(Fn); Fn->getParent()->getFunctionList().insert(Fn, NF); NF->takeName(Fn); for (Function::arg_iterator AI=F.arg_begin(), AE=F.arg_end(), NAI=NF->arg_begin(); AI != AE; ++AI, ++NAI) { NAI->takeName(AI); } // Since we have now create the new function, splice the body of the old // function right into the new function, leaving t...

...[0 x float] }* bitcast ({ i32, [5 x float] }* @g to { i32, [0 x float] }*) } Internally to your front end, you could do the same thing: Declare the global early with its abstract type, and later when the concrete storage type is known, use ConstantExpr::getBitCast, replaceAllUsesWith, and takeName to do the same thing the linker did above. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080420/e09e159d/attachment.html>

...\n"); // Something changed! Changed = true; ++NumSimplified; // Inspect the instruction after the call (which was potentially just // added) next. I = CI; ++I; if (CI != Result && !CI->use_empty()) { CI->replaceAllUsesWith(Result); if (!Result->hasName()) Result->takeName(CI); } CI->eraseFromParent(); Best regards, Christoph P.S. When answering, don't forget to CC the mailing list. On 18/06/2012 09:22, Thomson wrote: > Thanks for all your information. I got the pass in SimplifyLibCalls.cpp. > > I looked at the code, but am still a little confuse...

I'm now writing a pass and I wanna ask a question about how to duplicate the function and add duplicated arguments in llvm, for example: func(int a, char *b) -> func(int a, char *b, int a1, char *b1) I'm now stuck at using "getOrInsertFunction" and how to handle "getArgumentList", please share your opinion, thanks a lot! James

...)(void))(print1fPtr))(); EXPECT_EQ(0xdeadbeef, ret); However, when i try to replace the use of print1 with print2, it doesn't seem to work correctly. This is the sequence of steps that I am following: llvm::Function *print2f = main->getFunction( "print2" ); print2f->takeName( print1f ); llvm::Function *mainf = main->getFunction( "mainOfLibrary" ); ee->freeMachineCodeForFunction( mainf ); ee->freeMachineCodeForFunction( print1f ); print1f->replaceAllUsesWith( print2f ); print1f->deleteBody(); print1f->dropAllReferences();...

...call->getNumArgOperands())); callargs.insert(callargs.begin(), callee->getName()); CallInst* newcall = CallInst::Create(launch, callargs, "", call); newcall->takeName(call); newcall->setCallingConv(call->getCallingConv()); newcall->setAttributes(call->getAttributes()); newcall->setDebugLoc(call->getDebugLoc());...

...an, >> >>  After discovering several bugs in ArgumentPromotion and >>  DeadArgumentElimination where llvm::Functions were replaced with similar >>  functions (with the same name) to transform their type in some way, I >>  started looking at all calls to llvm::Function::takeName to see if there >>  were any other debug info quality bugs in similar callers. >> >>  One such caller is MergeFunctions, and I don't see any debug info tests >>  for this so I'm wondering what /should/ happen here. >> >>  In the case where the functions...

I found that LLVM optimized the IR by replacing printf with puts. I wondered which pass did this optimization? And is it common that puts is faster (and some other metric) than printf? -- Thanks Thomson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120617/08aa6c45/attachment.html>

Hi, I have a question about the llvm passes. I'm iterating over a basicblock and I can get an instruction and print it. Now, I want to iterate over the instruction and be able to modify the values of the instruction. For example, if my instruction is an add "<result> = add i32 4, %var" I want to transform it in a sub "<result> = sub i32 4, %var". I looked up

...r, > > > > After discovering several bugs in ArgumentPromotion and > > DeadArgumentElimination where llvm::Functions were replaced with similar > > functions (with the same name) to transform their type in some way, I > > started looking at all calls to llvm::Function::takeName to see if there > > were any other debug info quality bugs in similar callers. > > > > One such caller is the DataFlowSanitizer, and I don't see any debug info > > tests for this so I'm wondering what /should/ happen here. > > > > Is DFSan+DebugInfo some...

Question about "Pascal-style" arrays as mentioned in the reference guide. Suppose I have a global variable which points to a constant, variable length array. The question is, how can I assign an array of type "{ i32, [5 x float]}" to a global of type "{ i32, [0 x float]}"? From my experimentation, it appears you can't bitcast or call GEP on a constant

...ing several bugs in ArgumentPromotion and >>> > DeadArgumentElimination where llvm::Functions were replaced with >>> similar >>> > functions (with the same name) to transform their type in some way, I >>> > started looking at all calls to llvm::Function::takeName to see if >>> there >>> > were any other debug info quality bugs in similar callers. >>> > >>> > One such caller is the DataFlowSanitizer, and I don't see any debug >>> info >>> > tests for this so I'm wondering what /should...