[llvm-dev] LLVM IR linking separate function definitions in header files in single IR

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Sun Jan 6 09:15:27 PST 2019


On Sun, Jan 6, 2019 at 3:36 AM hameeza ahmed <hahmed2305 at gmail.com> wrote:

> Thank You..
> I am observing memory allocation instructions malloc and new operator in
> LLVM IR.
> In my considered benchmark memory is allocated using new operator as
> follows.
> *return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));*
>
> How can I observe such allocations in IR? I mean which instruction in IR
> is equivalent to above code i.e new operator.
>

I think I answered in my previous email: "The line you are posting above is
present multiple times, for example in the
function _ZN9__gnu_cxx13new_allocatorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE8allocateEmPKv"
and: "Calls to @_Znwm are allocating memory."

Did you search for these calls in the IR? Can you clarify what else you
need?

-- 
Mehdi



>
> Please help
> Thank You
>
> On Sun, Jan 6, 2019 at 4:32 AM Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>>
>>
>> On Sat, Jan 5, 2019 at 3:08 PM hameeza ahmed <hahmed2305 at gmail.com>
>> wrote:
>>
>>> Thank You...
>>> My issue is i m observing malloc instructions in LLVM IR.. When I
>>> compiled certain benchmark codes i.e graphbig. They consume memory but when
>>> I see IR there is no malloc..
>>>
>>
>> This is confusing, you first wrote that you are "observing malloc
>> instructions in LLVM IR" but then you wrote "when I see IR there is no
>> malloc".
>>
>>
>>
>>> By observing in detail i came to know following line which exist in
>>> header file new_allocator.h is taking memory;
>>> *return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));*
>>>
>>
>> Your original question was "I want to have a single IR with all the
>> definitions of the called functions that are implemented in header files".
>>
>> The IR you're sending contains all the code defined in the header. The
>> line you are posting above is present multiple times, for example in the
>> function _ZN9__gnu_cxx13new_allocatorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEE8allocateEmPKv
>>
>>
>>
>>> but in IR there is no malloc...
>>>
>>
>> Do you have calls to malloc in the source code?
>>
>>
>>> how can i identify such instructions in IR...by call void @_ZN??
>>> My IR is attached here..
>>>
>>
>> Calls to @_Znwm are allocating memory. They are not implemented in a
>> header:
>> https://code.woboq.org/gcc/libstdc++-v3/libsupc++/new_op.cc.html#50 (see
>> the call to malloc there).
>>
>> In general, calls to malloc can likely be caught at runtime: run in a
>> debugger and break into malloc.
>>
>> best,
>>
>> --
>> Mehdi
>>
>>
>>
>>
>>>
>>> Please help.
>>>
>>> On Fri, Jan 4, 2019 at 4:21 AM Mehdi AMINI <joker.eph at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jan 1, 2019 at 1:41 PM hameeza ahmed via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hello,
>>>>> I have different codes with separate files with functions implemented.
>>>>> I want to view all function definitions/ instructions in single IR. I am
>>>>> able to do this by llvm-link for codes which have definition implemented in
>>>>> .c files...
>>>>> But there are some codes which have definitions instructions in header
>>>>> files. These functions are called from .c file. I want to have a single IR
>>>>> with all the definitions of the called functions that are implemented in
>>>>> header files..
>>>>>
>>>>> How to do this?
>>>>> Please help...
>>>>>
>>>>
>>>> I assume that your  "function defined in a header"  are marked as
>>>> inline? There is no semantic concept of "header" in C/C++: moving code from
>>>> a .c to a .h (or renaming a file) does not change anything to what the
>>>> compiler will do with it.
>>>>
>>>> Depending on the language (GNU-C89, C99 vs C++, see here:
>>>> https://en.wikipedia.org/wiki/Inline_function ), the semantic of
>>>> inline functions is different.
>>>> If you can provide an minimal example it would be easier.
>>>>
>>>> Best,
>>>>
>>>> --
>>>> Mehdi
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190106/709af7e4/attachment.html>


More information about the llvm-dev mailing list