In LLVM IR, a "." and a number following a function name.
Such as
#kmalloc.2670，#kmalloc.19
What does this number mean?
It is often the situation that a same function name followed by different numbers. However, the definition code of the two functions are the same.
Can anybody help me?
define internal i8* #kmalloc.2670(i64 %size, i32 %flags) #5 !dbg !436635
define internal i8* #kmalloc.19(i64 %size, i32 %flags) #5 !dbg !1202009
Is this right?
LLVM docs:
One nice thing about LLVM is that the name is just a hint. For
instance, if the code above emits multiple “addtmp” variables, LLVM
will automatically provide each one with an increasing, unique numeric
suffix. Local value names for instructions are purely optional, but it
makes it much easier to read the IR dumps.
Related
I can easily find free in this IR call instruction with getCalledFunction():
call void #free(i8* %10) #4, !dbg !53
However, I can't seem to know how to find it in this call instruction:
%call7 = call i32 bitcast (i32 (...)* #free to i32 (%struct.Bar*)*)(%struct.Bar* %7), !dbg !56
This instruction is combining a BitCast with a call instruction. I am not sure if "combining" is the proper phrase, but nevertheless, how can I detect free here?
I tried dyn_cast to a Bitcast and it isn't. I even used getCalledOperand() first and tried casting the Value I get from it to a BitCast and it still isn't detecting it. I would appreciate any help with this.
Thanks!
#arnt answered this in the comments, so I'm adding the answer for everyone else.
#arnt: The first argument to the call is a ConstantExpr, returned by getBitCast. cast(foo)->getOperand(0) will return the free.
part of my project, based on some analysis, I have to change the function call's arguments. I am doing it in the llvm-ir level. something like this,
doWork("work",functionBefore)
based on my results my llvm-pass should be able to transform the function pointer passed to the function call like this
doWork("work",functionAfter)
assume both functionBefore and functionAfter have the same return type.
Is it possible to change the arguments using llvm pass?
Or should i delete the instruction and recreate the one I needed?
Please give some suggestions or directions how to do this ?
llvm ir to the call the function would be something like this-
invoke void #_Z7processNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPFvS4_E(%"c lass.std::__cxx11::basic_string"* nonnull %1, void (%"class.std::__cxx11::basic_string"*)* nonnull #_Z9functionBNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE) to label %7 unwind label %13
I have found myself with a reasonably large number of useful functions and constants written in LLVM's IR. I can use this pseudo-library by combining it with hand written IR, provided said hand written IR starts with a potentially lengthy list of declarations. I'm aware that IR isn't necessarily designed as a general purpose programming language to write stuff in.
This is much like writing a lot of C functions in one file then redeclaring them wherever they are used. In C this is worked around using #include and header files. That's not perfect, but it beats writing out the prototypes repeatedly.
What's the least nasty way to achieve something similar in IR? It only has to beat typing the stuff out over and over again (which I currently do in copy & paste fashion) and using cat as a custom build step.
Thanks!
Sadly there is no such thing in LLVM IR.
LLVM IR isn't designed to have large amounts of it written by hand. Therefore it doesn't have a #include mechanism. The job of handling that kind of stuff falls onto the compiler using the LLVM API.
One thing you could do however if you want to achieve the same effect is either to try to see if someone else's preprocessor will work for what you're trying to do or write a custom preprocessor yourself.
You can use llvm-link for combining different IRs together.
For example, you have the following sequence.
// file : f1.ll
; Function Attrs: nounwind readnone
define i32 #f1(i32 %a) #0 {
entry:
ret i32 %a
}
// file : f2.ll
; Function Attrs: nounwind
define i32 #f2(i32 %a) #0 {
entry:
%call = tail call i32 #f1(i32 %a) #2
ret i32 %call
}
Then you can call
llvm-link f1.ll f2.ll -S -o ffinal.ll
ffinal.ll would contain both IR codes.
I have generated an IR with my pass, inside a function in this IR, I would like to jump back to a basicblock of the caller function , inside caller function ext_callee function is invoked like this:
%4 = call i1 #ext_callee(i32 32, i32 %3, i32 -4, i8* blockaddress(#tobecalled, %5), i8* blockaddress(#tobecalled, %7)).
The last two parameters are the basicblock addresses I would like to jump to inside this ext_callee function.
I tried to use indirectbr instruction with one of the blockaddress parameters but when I run the IR it prompts segment fault. I searched LLVM documents but didn't find how to jump to basicblocks of another function. Does anyone have a clue? Thanks very much!
You cannot do this.
Per http://llvm.org/docs/LangRef.html#i-indirectbr:
Control transfers to the block specified in the address argument. All possible destination blocks must be listed in the label list, otherwise this instruction has undefined behavior. This implies that jumps to labels defined in other functions have undefined behavior as well.
I was trying to inline functions in llvm using this command:
opt -inline -inline-threshold=1000000 a.bc -o a.inline.bc
The (indirect) function calls involving pointer casts were not been able to inline. For eg.
%call4 = call i32 (...)* bitcast (i32 (%struct.token_type*)* #print_token to i32 (...)*)(%struct.token_type* %5)
But the functions calls like the one below are being inlined:
%call49 = call i32 #special(i32 %43)
Can I inline all the function calls irrespective of the fact whether they are direct or indirect??
Thanks!
You can't inline something if you don't know what it is, and a function pointer that is assigned at run time can not be know at any point during the build process... If it is defined in such a way as to be reassign-able then it couldn't be possibly inlined... Calling code could be inlined, but calls to function pointers can't be....
It is possible that there are some scenarios that could possibly be inlined that llvm is overly cautious about, but that would probably be an issue for the llvm dev list...
And you haven't given a concrete example to look at for someone wiser than me to look at, to know if it should be possible to inline in your scenario.