[llvm-dev] GlobalValue::AvailableExternallyLinkage

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 20 14:20:00 PST 2016


> On Nov 20, 2016, at 2:11 PM, Simone Atzeni <simone.at at gmail.com> wrote:
> 
>> 
>> On Nov 19, 2016, at 14:09, Mehdi Amini <mehdi.amini at apple.com> wrote:
>> 
>> I assume from your description that you are also updating call sites in the same module so that if foo was calling atoi, after cloning you have foo_parallel that is calling atoi_parallel? 
>> If this is the issue, it depends, I’d probably consider turning the available_externally into internal. But you can also run the eliminate_available_externally pass before performing your transformation.
> 
> No I am not updating call sites, I want the body of the function foo and foo_parallel to be the same.
>> 
>> As a side note, I wonder how are callers outside of the current module that are calling `foo()` supposed to call `foo_parallel()` after?
> 
> I insert some more code that basically check if the function is called within an OpenMP parallel region or not, if so the function foo will call foo_parallel.

But are you doing this only if foo_parallel exist in the current module?
I’m missing where the reference to atoi_parallel is introduced and causing the link failure.

— 
Mehdi




> 
> Simone
> 
>> 
>>>> Mehdi
>> 
>> 
>>> On Nov 19, 2016, at 12:57 PM, Simone Atzeni <simone.at at gmail.com> wrote:
>>> 
>>> Because what is happening is that if function “atoi” gets cloned I don’t have a definition of “atoi_parallel” therefore I get undefined references when linking.
>>> I just want to clone and instrument functions implemented in modules of my program.
>>> 
>>>> On Nov 19, 2016, at 13:54, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>> 
>>>> 
>>>>> On Nov 19, 2016, at 12:44 PM, Simone Atzeni <simone.at at gmail.com> wrote:
>>>>> 
>>>>> Thanks Mehdi.
>>>>> 
>>>>> My pass clones the functions within a module in order to have the original function and an exact copy of the same function but with a different name, i.e. sum() and sum_parallel().
>>>>> After my pass I will run ThreadSanitizer instrumentation pass only on the new copy of the functions, i.e. only the “_parallel” functions will be instrumented by tsan.
>>>>> 
>>>>> In some programs that I am compiling, the functions such as atoi and atof get cloned but I want to avoid this, and I noticed that only those functions have GlobalValue::AvailableExternallyLinkage, so I was wondering if checking the  linkage is enough to avoid those library functions or there could be situations of functions with that linkage but that have the body implemented in the same module.
>>>>> 
>>>>> Does it make sense now?
>>>> 
>>>> That gives me more context yes, now the question I’d have is maybe “why” you don’t want to instrument these function as well here?
>>>> Depending on the underlying criteria that motivate it, the answer can be different :)
>>>> 
>>>>>>>> Mehdi
>>>> 
>>>> 
>>>>> 
>>>>>> On Nov 19, 2016, at 13:32, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Nov 19, 2016, at 12:00 PM, Simone Atzeni via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> could anybody explain what GlobalValue::AvailableExternallyLinkage means?
>>>>>> 
>>>>>> It means that the function will not be codegen in this module, it will be available at link time from another object.
>>>>>> The IR is available for the purpose of inlining mainly.
>>>>>> 
>>>>>>> 
>>>>>>> I implemented an instrumentation pass that creates a clone of a function.
>>>>>>> For some programs I noticed that also function such as “atoi”, “atof”, “__strspn_c2”, etc. they get cloned even if I am not implementing them in the module.
>>>>>>> I would like to avoid cloning those functions, so I noticed that they have GlobalValue::AvailableExternallyLinkage linkage.
>>>>>>> Checking if they have GlobalValue::AvailableExternallyLinkage would it be enough to ignore them?
>>>>>> 
>>>>>> I don’t really understand what you’re doing or why, so I can’t answer this question.
>>>>>> 
>>>>>>>>>>>> Mehdi
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



More information about the llvm-dev mailing list