search for: nextinstr

...rate with C Code properly. Function *tmp = cast<Function>(Fn); tmp->setCallingConv(CallingConv::C); return true; } bool DP::runOnFunction(Function &F) { #if 0 Value *param; // Find the instruction before which you want to insert the function call Instruction *nextInstr = F.back().getTerminator(); // Create the actual parameter for the function call param = ConstantInt::get(Type::getInt32Ty(F.getContext()), 333); // create and insert the function call //CallInst::Create(f, param, "", nextInstr); CallInst::Create(Fn, param, "&qu...

...llingConv(CallingConv::C); Function *tmp = cast<Function>(Fn); tmp->setCallingConv(CallingConv::C); return true; } bool DP::runOnFunction(Function &F) { #if 1 Value *param; // Find the instruction before which you want to insert the function call Instruction *nextInstr = F.back().getTerminator(); // Create the actual parameter for the function call param = ConstantInt::get(Type::getInt32Ty(F.getContext()), 333); // create and insert the function call //CallInst::Create(f, param, "", nextInstr); CallInst::Create(Fn, param, "&qu...

> I enjoyed the new coding style in recent patches. Camel case makes it easy > to pick a descriptive name. Starting functions and variables with lower > cases reduces chances to conflict with a type name. Honestly speaking, I don't. Especially in the cases when varname is made from an acronym. E.g. MachineInstr *MI looks much better than MachineInstr *mi, etc. See latest Rafael's

...Csaba has pointed out the problem of possible clash (at least confusion) with macro names for variable names like MI. I agree that 'mi' is not a great name either in this case. In fact, it's not even camel case. How about instr? Or, perhaps a name that clarifies its role (jumpInstr, nextInstr, etc)? Or, if this is a short-lived local variable, I'd be fine with 'mi'. Cheers, -- Zhanyong

Hi, I enjoyed the new coding style in recent patches. Camel case makes it easy to pick a descriptive name. Starting functions and variables with lower cases reduces chances to conflict with a type name. 2010/11/23 Zhanyong Wan (λx.x x) <wan at google.com> > On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: > > +llvmdev > > >