search for: oldinst

...nstruction. As long as the type generated by the old and new instructions is identical (or maybe even similar), you shouldn't have any problems. For example, replacing an add instruction that adds two i32's with a call instruction that returns an i32 should be as simple as: Instruction * OldInst = ... ; Instruction * NewInst = CallInst::Create (...); OldInst->replaceAllUsesWith (NewInst); This sort of code may not work if OldInst and NewInst are not SSA virtual registers of the same type (for example, if OldInst is a pointer to an array of i32 and NewInst is a pointer to a structure)....

Hello everyone, is there any way to replace an instruction inside LLVM that is more elegant than creating a new one, replacing uses and deleting the old one if I only want to modify the type? It is generally not a big deal, but the issue gets really messy if I am in the middle of iterating over uses and start deleting some of them... I hope I could describe my problem well enough ;) Regards,

...nstance, >> given the instruction "%3 = add i32 %1, %2" I would like to alter the >> instruction to "%3 = add i16 %1, %2". Is there any way to do this? >> > > No. Instead you create a new Instruction, in this case with > BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst) to > update all the users, then OldInst->eraseFromParent() since it's now dead > code. > > Also, all values have types immutably assigned at creation, so you'll need > to insert casts (trunc instructions in your case) to cast %1 and %2 from...

...an integer variable. For instance, > given the instruction "%3 = add i32 %1, %2" I would like to alter the > instruction to "%3 = add i16 %1, %2". Is there any way to do this? > No. Instead you create a new Instruction, in this case with BinaryOperator::CreateAdd, then OldInst->replaceAllUsesWith(NewInst) to update all the users, then OldInst->eraseFromParent() since it's now dead code. Also, all values have types immutably assigned at creation, so you'll need to insert casts (trunc instructions in your case) to cast %1 and %2 from i32 to i16 for the small...

...0 and V1 you created were never inserted into the BasicBlock so they can't be numbered, and also they don't have names. > What I am doing wrong? Suppose that you're going from i32 to i16. Your only choice with that particular pair of types is a truncate. So: IRBuilder builder(OldInst); Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty()); Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty()); Value *Add = builder.CreateNSWAdd(V0, V1, "test"); The IRBuilder will take care of the distinction between instructions and constants for you. Note that I have...

Hello guys, I wonder how I can change the type of an integer variable. For instance, given the instruction "%3 = add i32 %1, %2" I would like to alter the instruction to "%3 = add i16 %1, %2". Is there any way to do this? Best wishes, Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL:

...to the > BasicBlock so they can't be numbered, and also they don't have names. > > > What I am doing wrong? >> > > Suppose that you're going from i32 to i16. Your only choice with that > particular pair of types is a truncate. So: > > IRBuilder builder(OldInst); > Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty()); > Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty()); > Value *Add = builder.CreateNSWAdd(V0, V1, "test"); > > The IRBuilder will take care of the distinction between instructions and > constants for...

...Can't handle other instructions + return 0; + } + } + // Insert a new bitcast, if needed + Value *NewVal = InsertBitCastBefore(CI.getOperand(0), NTy, CI); + + for (User::use_iterator I = CI.use_begin(), E = CI.use_end(); I != E; ++I) { + Instruction *NewInst; + Instruction *OldInst = cast<Instruction>(*I); + // Declare this here, so we can reuse the dyn_cast + GetElementPtrInst *GEP = NULL; + // Create a new instruction + if (isa<StoreInst>(*I)) + NewInst = new StoreInst(I->getOperand(0), NewVal); + else if ((GEP = dyn_cast<GetElementPtrI...

...o they can't be numbered, and also they don't > have names. > > > What I am doing wrong? > > > Suppose that you're going from i32 to i16. Your only choice with > that particular pair of types is a truncate. So: > > IRBuilder builder(OldInst); > Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty()); > Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty()); > Value *Add = builder.CreateNSWAdd(V0, V1, "test"); > > The IRBuilder will take care of the distinction between > instruction...

...9;t be numbered, and also they don't have names. >> >> >> What I am doing wrong? >>> >> >> Suppose that you're going from i32 to i16. Your only choice with that >> particular pair of types is a truncate. So: >> >> IRBuilder builder(OldInst); >> Value *V0 = builder.CreateTrunc(Op0, Type::getInt16Ty()); >> Value *V1 = builder.CreateTrunc(Op1, Type::getInt16Ty()); >> Value *Add = builder.CreateNSWAdd(V0, V1, "test"); >> >> The IRBuilder will take care of the distinction between instructions and...

...eturn 0; > + } > + } > + // Insert a new bitcast, if needed > + Value *NewVal = InsertBitCastBefore(CI.getOperand(0), NTy, CI); > + > + for (User::use_iterator I = CI.use_begin(), E = CI.use_end(); I ! > = E; ++I) { > + Instruction *NewInst; > + Instruction *OldInst = cast<Instruction>(*I); > + // Declare this here, so we can reuse the dyn_cast > + GetElementPtrInst *GEP = NULL; > + // Create a new instruction > + if (isa<StoreInst>(*I)) > + NewInst = new StoreInst(I->getOperand(0), NewVal); > + else if ((GE...

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

...n constructors. This could be in the form of a pure DebugLoc variable or possibly an `Instruction *InheritLocationFromInst` one Some pros of this idea are: - Easier to create instructions with debug location. - It will make the code more readable by eliminating the many `NewInst->setDebugLoc(OldInst->getDebugLoc)` calls. - It will incentivize people to think about the DebugLoc of their newly created instruction and where it should come from. As the Create() functions are widely used, and sometimes location data could be out of scope when the Instruction is created, I think the best appro...

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli