<div class="gmail_quote">On 13 January 2010 12:05, Mark Muir <span dir="ltr"><<a href="mailto:mark.i.r.muir@gmail.com">mark.i.r.muir@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 13 Jan 2010, at 16:43, Nick Lewycky wrote:<br>
<div class="im"><br>
> Mark Muir wrote:<br>
>> - Run the existing Clang tool on each source file, using -emit-llvm to generate a .bc file for each module.<br>
>> - Run llvm-link to merge them into a single .bc file.<br>
>> - Run llc to generate a complete machine assembly.<br>
>><br>
</div><div class="im">>> However, with optimisations enabled, the resulting code is not as efficient as it would be if all the code were in a single module. In particular, function inlining is only performed by clang (i.e. only on a module-by-module basis), and not by llvm-link or llc.<br>
><br>
</div><div class="im">> It sounds like you're not running the LTO optimizations. You could try replacing llvm-link with llvm-ld which will, or run 'opt -std-link-opts' between llvm-link and llc.<br>
><br>
<br>
</div>Yep, that sorted inlining. Thanks.<br>
<br>
But... now there's a small problem with library calls. Symbols such as 'memset', 'malloc', etc. are being removed by global dead code elimination. They are implemented in one of the bitcode modules that are linked together (implementations are based on newlib).</blockquote>
<div><br>And what problems does that cause? If malloc is linked in, we're free to inline it everywhere and delete the symbol. If you meant for it to be visible to the optimizers but you don't want it to be part of the code generated for your program (ie., you'll link it against newlib later), you should mark the functions with available_externally linkage.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I get the same behaviour of them being stripped even when they are live, by the following:<br>
<br>
opt -internalize -globaldce<br>
<br>
Other (not standard-library) functions implemented in different modules than where they are called, are correctly seen as live. So, could this be something to do with what is declared as a built-in? I haven't provided any list of built-ins (or overridden the defaults), nor could I figure out how exactly to do that.<br>
</blockquote><div><br>Alternately, if you wanted malloc, memset and friends to be externally visible (compiled as part of your program and dlsym'able), you could create a public api file which contains a one per line list of the names of the functions that may not be marked internal linkage by internalize. Pass that in to opt with -internalize-public-api-file filename ...other flags...<br>
<br>Nick<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've also noticed other problems related to built-ins - in one example, code made use of abs(), but didn't #include <stdlib.h>. The resulting code compiled without warning or error, but the resulting code was broken, due to the arguments not being seen as live, e.g.:<br>
<br>
Without #include <stdlib.h>:<br>
<br>
0x181e8b0: i32 = TargetGlobalAddress <i32 (...)* @abs> 0 [TF=1]<br>
=> JUMP_CALLi <ga:abs>[TF=1], %r2<imp-def>, %r3<imp-def>, %r4<imp-def,dead>, %r5<imp-def,dead>, %r6<imp-def,dead>, %r7<imp-def,dead>, %r8<imp-def,dead>, %r9<imp-def,dead>, %r10<imp-def,dead><br>
<br>
With #include <stdlib.h>:<br>
<br>
0x181e8b0: i32 = TargetGlobalAddress <i32 (i32)* @abs> 0 [TF=1]<br>
=> JUMP_CALLi <ga:abs>[TF=1], %r3<kill>, %r2<imp-def>, %r3<imp-def>, %r4<imp-def,dead>, %r5<imp-def,dead>, %r6<imp-def,dead>, %r7<imp-def,dead>, %r8<imp-def,dead>, %r9<imp-def,dead>, %r10<imp-def,dead><br>
<br>
Where r2 is the link register, and r3 to r10 are argument/retval registers. LowerFormalArguments() doesn't see any arguments in the former, and consequently doesn't add input register nodes to the DAG.<br>
<br>
I guess I need help with the concept of built-ins, and what code is related to them in the Clang driver and back-end.<br>
<div><div></div><div class="h5"><br>
Regards,<br>
<br>
- Mark<br>
<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>
</div></div></blockquote></div><br>