[LLVMdev] Understanding tail calls

Scott Ricketts sricketts at maxentric.com
Thu Mar 18 08:19:26 PDT 2010


> I don't really understand what you are asking.  In general a function with
> weak linkage may or may not be replaced by another at link time, but you
> can't tell before link time.  For example, suppose a function called F (I
> will refer to this as F1) has weak linkage.  If at link time you link with
> another object file that also defines a function called F (I will refer to
> this as F2) but not with weak linkage, then F1 will be discarded and F2 is
> what will end up in the executable.  On the other hand, suppose F2 also has
> weak linkage, then I think one of F1/F2 is chosen essentially randomly.
> Finally, if at link time no other object file defines a function called F
> then F1 will be used.  So what happens is determined by what the user passes
> to the linker, and as such is not known at compile time.
>
> A philosophical remark: if you could tell at compile time which function
> bodies will be in the final executable, then there would be no point in
> having weak linkage: if you can tell that the function body is not going
> to be used then you might as well throw it away (i.e. replace with a
> declaration) and not bother optimizing it; on the other hand, if you are
> sure that it is going to be used then you might as well give it strong
> linkage.

OK this makes sense, thanks for the example and the general comment.

Let me be a bit more clear about my problem. I am instrumenting code
with an opt pass. If I come across a CallInst, the way I instrument it
depends on whether the body of the callee will also be instrumented.
If the callee is some function in, say, a dynamically loaded share
library, it won't be instrumented (because I am not running the
library through my pass). Previously, I assumed that as long as I
could see the function definition in the module, it was safe to assume
that I was going to instrument it. But I recently came across examples
where the function definition from a dynamically loaded library was
brought in and assigned linkonce_odr. I would instrument that
definition, but then that definition was not used at link time, so my
instrumented code was broken.

So I actually don't care which version of the function gets finally
linked, but I do care whether or not it is a version that actually
runs through my opt pass. Does that make more sense?

However, from your philosophical comment, it seems like in general
this is not going to be possible. It also sounds like I need to
educate myself a bit more about linkage, beyond just the LLVM docs.

Thanks,
Scott




More information about the llvm-dev mailing list