Applying a “wrong” DebugLoc to an Instruction will not cause any errors. The “wrong” location would be carried through to the debugging information in the object file, which might cause your debugger to do something unexpected while debugging the program.
One tactic, which ought to be fairly easy, is to give your new Instruction the same DebugLoc as the Instruction before (or after) your new Instruction. This will make your new Instruction appear to be part of the same source statement as the neighboring Instruction.
I am not able to add icmp instruction using IRbuilder after the function call instruction (I was able to add icmp instruction using IRbuilder after other instructions, e.g. mul instruction): I wrote a pass(snippet below) to do the above instrumentation which also adds other new instructions, running the pass with opt does not throw any error when there is a CreateIcmpEQ with two constant operands, but only the icmp instruction after the function call is not present in the instrumented IR.
How to pass the output of a function call to CreateIcmpEQ() as a argument? I understand that fooRet is the return value of my call instruction. When I use check = builder.CreateICmpEQ(call, newConst, “check”), I get a Type mismatch assert. [ICmpInst::AssertOK(): Assertion 'getOperand(0)->getType() == getOperand(1)->getType() && “Both operands to Icmp instruction are not of the same type!”]. I guess if I can make the types match, I will be able to pass the return value as argument. How can I achieve that?
A snippet of the pass:
if(CallInst call = dyn_cast(&I))
{
call->setName(“fooRet”);
IRBuilder<> builder(call);
Value newConst = ConstantInt::get(Int32Ty,55);
Value* before = builder.CreateAlloca(Int32Ty, newConst,“before”);
builder.SetInsertPoint(&bb, ++builder.GetInsertPoint()); Value* check = builder.CreateICmpEQ(call, newConst, “check”);
auto * branch = builder.CreateCondBr(check, true, false);