Thanks,Cheers!
I found the problem is that the "Function *call_print" using the same
name
as the “class call_print”, which made the compiler wrongly resolved the
call_print type!
But I got another problems. I successfully compile the pass and I can
insert the call printf (C Lib function) instructions in the LLVM IR(eg:
call.bc). If the call.bc didn't contain call printf instruction ,I can
call printf successfully ,but if not ,there exists a problem. the llvm will
rename my inserted call function , and the transformed code can not run
correctly!
the original .bc file:
; ModuleID = 'call.bc'
target datalayout
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1
; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
%retval = alloca i32, align 4
%a = alloca i32, align 4
store i32 0, i32* %retval
store i32 3, i32* %a, align 4
%0 = load i32* %a, align 4
%call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x
i8]* @.str, i32 0, i32 0), i32 %0)
%1 = load i32* %a, align 4
ret i32 %1
}
//contains call printf
declare i32 @printf(i8*, ...) #1
attributes #0 = { nounwind uwtable
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
here is the .bc file that I get after the transform:
; ModuleID = 'call.opt.bc'
target datalayout
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@.str = private unnamed_addr constant [4 x i8] c"%d\0A\00", align 1
@.str2 = private constant [4 x i8] c"%d\0A\00"
; Function Attrs: nounwind uwtable
define i32 @main() #0 {
entry:
%retval = alloca i32, align 4
%a = alloca i32, align 4
store i32 0, i32* %retval
// this is the instruction that I inserted ,which calls a C Lib
"printf"
%0 = call i32 (i8*, ...)* @printf1(i8* getelementptr inbounds ([4 x i8]*
@.str2, i32 0, i32 0), i32 2)
store i32 3, i32* %a, align 4
%1 = load i32* %a, align 4
%call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x
i8]* @.str, i32 0, i32 0), i32 %1)
%2 = load i32* %a, align 4
ret i32 %2
}
declare i32 @printf(i8*, ...) #1
// if the program didn't contain call printf instruction ,this declaration
should be as the one above,but now it was renamed and can not be resolved
declare i32 @printf1(i8*, ...)
attributes #0 = { nounwind uwtable
"less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
attributes #1 = { "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf"="true"
"no-infs-fp-math"="false"
"no-nans-fp-math"="false"
"unsafe-fp-math"="false"
"use-soft-float"="false" }
Is there any method to avoid the rename manipulation ?
Thanks!
2013/12/16 Tim Northover <t.p.northover at gmail.com>
> Hi Jin,
>
> It's difficult to say just from looking at a pass, but one thing looked
> odd:
>
> > CallInst *call_print >
CallInst::Create(call_print,paramArrayRef,"",ins_temp);
>
> This looks very dodgy. The "call_print" being used as an argument
is
> the (uninitialised) one that's just been declared. This could be the
> source of the assertion failure (though a segfault is just as likely).
>
> Other than that I'd suggest hooking up a debugger and going up the
> call frames when that assertion hits. That should tell you exactly
> which line of your pass is causing trouble.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131217/321ff37e/attachment.html>