<div dir="ltr">Hi Johannes,<div><br></div><div>After reconsideration, I think your guess that the dependencies should be handled manually is reasonable. Because otherwise, if the dependencies are resolved automatically as I previously hoped, there might be an issue of redefinition of functions when multiple top functions share the same callees from library.</div><div><br></div><div>So, forget about the automatic dependence resolving stuff. I think this question is done and can be closed now.</div><div>Again, thanks for the helpful script, Johannes.</div><div>Cheers;)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 20, 2014 at 5:06 PM, Johannes Doerfert <span dir="ltr"><<a href="mailto:doerfert@cs.uni-saarland.de" target="_blank">doerfert@cs.uni-saarland.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Liwei,<br>
<br>
I inlined two comments but in short: I don't have a solution for your<br>
automatic dependence gathering problem.<br>
<span class=""><br>
On 09/20, Liwei Yang wrote:<br>
> Hi Johannes,<br>
><br>
</span><span class="">> Actually, I'm working in the same scenario, i.e. configure + make of a<br>
> benchmark/program/library like you said. I've got your point of using this<br>
> script as a replacement to generate .bc files instead of a executable.<br>
> That's truly helpful and has already answered my original question.<br>
><br>
> Now I'm actually moving a step further. Take the same example in your<br>
> reply, say, if I have a bunch of .c files, where a.c calls functions<br>
> defined in b.c, b.c calls functions defined in c.c and so on. I know that I can<br>
> compile them into a .bc file by using this command:<br>
> ~/llvm_link -I <HEADER_DIR> a.c b.c c.c d.c -emit-llvm -c -o linked.bc<br>
><br>
> But the problem is all of the files which define the callees need to be<br>
> specified manually. Is it possible that the source files in which the<br>
> callees are defined can be automatically inferred, compiled and linked? If<br>
> so, then we can just simply use this command below to include all the<br>
> callees required by in a.c:<br>
> ~/llvm_link -I <HEADER_DIR> a.c -emit-llvm -c -o linked.bc<br>
</span>I don't think this is in general even decidable and I'm not aware of any<br>
implemented approximation to that problem. If such a thing would exist we<br>
wouldn't need to write build dependences in Makefiles(.in) by hand any more ;)<br>
<span class=""><br>
> Though we can define the dependency for the source files defining callees<br>
> in makefile, it's still a manual specification there. So that's why I'm<br>
> looking into this further step.<br>
</span>My guess is you have to go the extra mile and define all dependences in<br>
a Makefile yourself.<br>
<br>
I hope you'll find a way that works for you,<br>
  Johannes<br>
<div class="HOEnZb"><div class="h5"><br>
> On Sat, Sep 20, 2014 at 10:53 AM, Johannes Doerfert <<br>
> <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a>> wrote:<br>
><br>
> > Hey Liwei,<br>
> ><br>
> > the script was "designed" to act as a compile during "the usual"<br>
> > configure + make of a benchmark/program/library. If you have such a setup<br>
> > (a configure script which will produce the Makefile file), you can do<br>
> > something similar to:<br>
> ><br>
> > ln -s ~/llvm_link.py ~/llvm_link<br>
> > ln -s ~/llvm_link.py ~/llvm_link++<br>
> ><br>
> > export CC=~/llvm_link<br>
> > export CXX=~/llvm_link++<br>
> ><br>
> > cd <SRC><br>
> > ./configure<br>
> > make<br>
> ><br>
> > and it should result in a .bc file where otherwise an e.g., an<br>
> > executable would have been produced.<br>
> ><br>
> > If you just have a bunch of .c files which can be compiled into an<br>
> > executable with:<br>
> ><br>
> > clang -I <HEADER_DIR> a.c b.c c.c d.c -o ex<br>
> ><br>
> > you can replace clang by the script and it should give you a ex.bc in<br>
> > the end.<br>
> ><br>
> > Does that help?<br>
> ><br>
> > Best regards,<br>
> >   Johannes<br>
> ><br>
> > On 09/20, Liwei Yang wrote:<br>
> > > Hi Johannes,<br>
> > ><br>
> > > By following your directions, I can use your script as is to produce the<br>
> > > .bc file now. Here's my command line for compiling s_sin.c into s_sin.bc<br>
> > > file and the output:<br>
> > > command line:<br>
> > > ~/Downloads/newlib-2.1.0/newlib/libm/mathfp » python ~/llvm_link.py<br>
> > s_sin.c<br>
> > > -I../common/ -I../../libc/include/ -o s_sin.bc<br>
> > ><br>
> > > output:<br>
> > > Initiate CLANG (/path-to-clang):<br>
> > >      Options: 's_sin.c -I../common/ -I../../libc/include/ -o s_sin.bc<br>
> > > -emit-llvm -c'<br>
> > > In file included from s_sin.c:18:<br>
> > > ./zmath.h:7:9: warning: 'NAN' macro redefined<br>
> > > #define NAN 2<br>
> > >         ^<br>
> > > ../../libc/include/math.h:57:11: note: previous definition is here<br>
> > > #  define NAN (__builtin_nanf(""))<br>
> > >           ^<br>
> > > 1 warning generated.<br>
> > >      Retcode: 0<br>
> > ><br>
> > > I don't know why this warning gets generated since in<br>
> > > ../../libc/include/math.h:57 the macro NAN is wrapped by ifndef as shown<br>
> > > below, but that's not important.<br>
> > > # ifndef NAN<br>
> > > #  define NAN (__builtin_nanf(""))<br>
> > > # endif<br>
> > ><br>
> > ><br>
> > > I llvm-dis this s_sin.bc file and get a s_sin.ll file as follows.<br>
> > > ; Function Attrs: nounwind uwtable<br>
> > > define double @sin(double %x) #0 {<br>
> > > entry:<br>
> > >   %x.addr = alloca double, align 8<br>
> > >   store double %x, double* %x.addr, align 8<br>
> > >   %0 = load double* %x.addr, align 8<br>
> > >   %call = call double @sine(double %0, i32 0)<br>
> > >   ret double %call<br>
> > > }<br>
> > ><br>
> > > declare double @sine(double, i32) #1<br>
> > ><br>
> > > Now here comes the point. In this bitcode file, the callee of sin()<br>
> > > function, i.e. sine(), does not have a function body. I know that the<br>
> > > definition of sine() is in another .c file, which is s_sine.c in the same<br>
> > > folder. So essentially, I'm wondering if the script can help to<br>
> > > automatically compile and link all the callees recursively required by<br>
> > > sin() without manually specifying every source file of the callees.<br>
> > ><br>
> > > Sorry for coming back late on this topic and thank you so much Johannes,<br>
> > > for sharing your helper script.<br>
> > ><br>
> > ><br>
> > > On Tue, Sep 16, 2014 at 9:00 PM, Johannes Doerfert <<br>
> > > <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a>> wrote:<br>
> > ><br>
> > > > Hey Liwei,<br>
> > > ><br>
> > > > I attached a script I used some time back to compile multiple source<br>
> > > > files (of a benchmark) into one bitcode file (instead of an<br>
> > executable).<br>
> > > > The script is very simple but worked surprisingly well. It checks the<br>
> > > > command line options for indicators what kind of output is expected and<br>
> > > > produces bitcode files with the appropriate names. In order to use it<br>
> > > > you just need to put/link the script on your path and use it as your<br>
> > > > standard compiler (e.g., export CC=<script_name>) instead of clang.<br>
> > > > However, clang and llvm-link need to be on the path. If the name of the<br>
> > > > executed script is <script_name>++ (note the ++ in the end) then<br>
> > clang++<br>
> > > > will be used to compile the source files, otherwise clang. Also note<br>
> > that<br>
> > > > the script will remove some command line options as they are not<br>
> > supported<br>
> > > > or desired when creating bitcode instead of object code files.<br>
> > > ><br>
> > > > It should also be able to pass a usual autoconf configure run by<br>
> > > > detecting it and simply redirecting the complete command line to<br>
> > clang(++).<br>
> > > > But I never used it to link libraries though.<br>
> > > ><br>
> > > > I'm not sure if you can use this script as is or as a starting point to<br>
> > > > create your own but maybe you can.<br>
> > > ><br>
> > > ><br>
> > > > Best regards,<br>
> > > >   Johannes<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > On 09/15, Liwei Yang wrote:<br>
> > > > > Good tips. Although I have used llvm-link to merge .bc files<br>
> > together, I<br>
> > > > > guess -flto could optimize the resultant .bc file further.<br>
> > > > ><br>
> > > > > As for the assembly, yes it is an issue. Anyway, I'll try to address<br>
> > > > those<br>
> > > > > sources which are available for being translated into .bc first.<br>
> > > > ><br>
> > > > > Thanks for your advice, Tim.<br>
> > > > ><br>
> > > > > On Mon, Sep 15, 2014 at 2:55 PM, Tim Northover <<br>
> > <a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>><br>
> > > > > wrote:<br>
> > > > ><br>
> > > > > > > If there's any automated way to infer about all the subroutines<br>
> > that<br>
> > > > one<br>
> > > > > > > function needs, clang them into .bc file and link them into a<br>
> > > > stand-alone<br>
> > > > > > > .bc library, that will be more than appreciated:-)<br>
> > > > > ><br>
> > > > > > If manually compiling the files is working for you, you could try<br>
> > > > > > building the entire library with "-flto" for Link-time<br>
> > optimisation.<br>
> > > > > > The output of that will be LLVM IR (if you can convince the build<br>
> > > > > > system to do it for you).<br>
> > > > > ><br>
> > > > > > The issue is that parts of the standard library are<br>
> > > > > > performance-critical and often written in assembly. If the entire<br>
> > file<br>
> > > > > > is assembly you won't be able to produce IR very easily at all.<br>
> > > > > ><br>
> > > > > > Cheers.<br>
> > > > > ><br>
> > > > > > Tim.<br>
> > > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > --<br>
> > > > > Best Regards<br>
> > > > > Liwei<br>
> > > ><br>
> > > > > _______________________________________________<br>
> > > > > LLVM Developers mailing list<br>
> > > > > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> > > > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > ><br>
> > > > Johannes Doerfert<br>
> > > > Researcher / PhD Student<br>
> > > ><br>
> > > > Compiler Design Lab (Prof. Hack)<br>
> > > > Saarland University, Computer Science<br>
> > > > Building E1.3, Room 4.26<br>
> > > ><br>
> > > > Tel. <a href="tel:%2B49%20%280%29681%20302-57521" value="+4968130257521">+49 (0)681 302-57521</a> : <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a><br>
> > > > Fax. <a href="tel:%2B49%20%280%29681%20302-3065" value="+496813023065">+49 (0)681 302-3065</a>  :<br>
> > <a href="http://www.cdl.uni-saarland.de/people/doerfert" target="_blank">http://www.cdl.uni-saarland.de/people/doerfert</a><br>
> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Best Regards<br>
> > > Liwei<br>
> ><br>
> > --<br>
> ><br>
> > Johannes Doerfert<br>
> > Researcher / PhD Student<br>
> ><br>
> > Compiler Design Lab (Prof. Hack)<br>
> > Saarland University, Computer Science<br>
> > Building E1.3, Room 4.26<br>
> ><br>
> > Tel. <a href="tel:%2B49%20%280%29681%20302-57521" value="+4968130257521">+49 (0)681 302-57521</a> : <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a><br>
> > Fax. <a href="tel:%2B49%20%280%29681%20302-3065" value="+496813023065">+49 (0)681 302-3065</a>  : <a href="http://www.cdl.uni-saarland.de/people/doerfert" target="_blank">http://www.cdl.uni-saarland.de/people/doerfert</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Best Regards<br>
> Liwei<br>
<br>
--<br>
<br>
Johannes Doerfert<br>
Researcher / PhD Student<br>
<br>
Compiler Design Lab (Prof. Hack)<br>
Saarland University, Computer Science<br>
Building E1.3, Room 4.26<br>
<br>
Tel. <a href="tel:%2B49%20%280%29681%20302-57521" value="+4968130257521">+49 (0)681 302-57521</a> : <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a><br>
Fax. <a href="tel:%2B49%20%280%29681%20302-3065" value="+496813023065">+49 (0)681 302-3065</a>  : <a href="http://www.cdl.uni-saarland.de/people/doerfert" target="_blank">http://www.cdl.uni-saarland.de/people/doerfert</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Best Regards<br>Liwei<br>
</div>