llvm dev - Sep 2014 - [LLVMdev] How to translate library functions into LLVM IR bitcode?

Thanks for your reply, Yabin.

Actually I'm trying to come up with a way to translate any source code into
bitcode format. So some of them are not necessarily LLVM intrinsics. Also
it seems like that dynamically loading the library by dlopen() is for
loading object files, not .bc files. So it might not be useful for library
in .bc files.
Anyway, I've found a way to solve this by manually compiling each of the
source file into a .bc file.

If there's any automated way to infer about all the subroutines that one
function needs, clang them into .bc file and link them into a stand-alone
.bc library, that will be more than appreciated:-)



On Mon, Sep 15, 2014 at 11:30 AM, Yabin Hu <yabin.hwu at gmail.com> wrote:
> Hi Liwei,
>
> You may at first look into whether there is a llvm intrinsic for the
> function you want to call. In case there is not, I would suggest you
> wrapped the original function in your own project and call the wrapped one
> instead. And at last you may dynamically load the original library and link
> to it at runtime (using dlopen).
>
> Regards,
> Yabin
>
> 2014-09-14 11:49 GMT+08:00 Liwei Yang <yangliwei.uestc at gmail.com>:
>
>> Hello,
>>
>> I run into a situation where I need to provide the library functions,
>> such as sqrt() from <math.h> and rand() from <stdlib.h>, in
the format of
>> LLVM IR bitcode files. Then I can try to link the bitcode of my program
>> against these library bitcode files to formulate a holistic bitcode
file.
>>
>> However, these library functions are only available in object format.
And
>> the source files of them I found have many references to other library
>> files.
>>
>> So, is there any way to translate the library source files into bitcode
>> files, so that all the information that the library functions need is
>> included and can provide the implementation of these functions to the
>> calling program after linking?
>>
>> Thanks for any suggestions:)
>>
>> --
>> Best Regards
>> Liwei
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>

-- 
Best Regards
Liwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140915/2be45925/attachment.html>

> If there's any automated way to infer about all the subroutines that
one
> function needs, clang them into .bc file and link them into a stand-alone
> .bc library, that will be more than appreciated:-)
If manually compiling the files is working for you, you could try
building the entire library with "-flto" for Link-time optimisation.
The output of that will be LLVM IR (if you can convince the build
system to do it for you).

The issue is that parts of the standard library are
performance-critical and often written in assembly. If the entire file
is assembly you won't be able to produce IR very easily at all.

Cheers.

Tim.

Good tips. Although I have used llvm-link to merge .bc files together, I
guess -flto could optimize the resultant .bc file further.

As for the assembly, yes it is an issue. Anyway, I'll try to address those
sources which are available for being translated into .bc first.

Thanks for your advice, Tim.

On Mon, Sep 15, 2014 at 2:55 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> > If there's any automated way to infer about all the subroutines
that one
> > function needs, clang them into .bc file and link them into a
stand-alone
> > .bc library, that will be more than appreciated:-)
>
> If manually compiling the files is working for you, you could try
> building the entire library with "-flto" for Link-time
optimisation.
> The output of that will be LLVM IR (if you can convince the build
> system to do it for you).
>
> The issue is that parts of the standard library are
> performance-critical and often written in assembly. If the entire file
> is assembly you won't be able to produce IR very easily at all.
>
> Cheers.
>
> Tim.
>


-- 
Best Regards
Liwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140915/785580e2/attachment.html>