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.
Hope this helps,
--paulr
Dear all,
I am trying to build a pass which compares the output of all function calls with a predefined value. I encountered two issues.
For example, the following IR
.....
%before = alloca i32, i32 55
%fooRet = call i32 @foo(i32 10)
.....
should be transformed to the following IR after the pass
....
%before = alloca i32, i32 55
%fooRet = call i32 @foo(i32 10)
%check = icmp eq i32 %call, i32 %before
br i1 %check label %3, label %4
...
1) 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.
A snippet of the pass:
if(CallInst *call = dyn_cast<CallInst>(&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);
}
Any help is appreciated. Thank you.
Regards,
Archanaa