In order to handle a large vector based math library I link in a fairly large bitcode file that might or might not be needed. The problem is that linking in this bitcode file drastically increases the amount of compile time required. Is there a way to remove all functions that are not used after this linking pass? Something similar to die but removes functions from the compilation unit instead of instructions.
Thanks,
Micah
The -globaldce pass will remove dead internal globals and functions.
-Chris
I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file.
The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file.
Any idea’s how to do this with the current llvm toolset?
Thanks,
Micah
I thought this pass would do it, but when I run it over my bc file the output file is the same as the input file.
that’s probably because your symbols are not internal.
The issue I guess is a little different. When I link in the huge bc file with the tiny bc file, I only want the resulting bc file to have the function definitions that the tiny bc file requires and not every function in the huge bc file.
Any idea’s how to do this with the current llvm toolset?
You have to roll your own using the lower level APIs. You can move functions between modules etc. Alternatively, you can link the two modules and mark the functions you don’t want as internal, then use globaldce.
-Chris
Is there a way to mark all functions as internal from source via some sort of attribute?
Thanks for the tips,
Micah
Is there a way to mark all functions as internal from source via some sort of attribute?
“static”. However, if you do that, they won’t make it into the bc file.
-Chris
A flag to force them into the .bc file would be a nice feature for
clang. Unfortunately, I don't expect it to be urgent enough for me to
submit a patch any time soon.
You can get that by marking them attribute(used), but then globaldce won't strip them. Perhaps the best option is to use the internalize pass, which marks a set of functions internal.
-Chris
Yeah, I found that out, which is why I was hoping some kind of attribute existed that the compiler knew about.
We might go the path of modifying llvm-link to only link in functions that are required as that seems to be the most optimal way of doing it.
Thanks,
Micah
If you care about performance, then you should consider a completely different approach. It is really inefficient to load a large volume of code and then delete it as dead. I strongly recommend watching Nate’s talk at the last llvm developer meeting.
-Chris
Hi,
Chris Lattner wrote:
Hello Paul,
The one I downloaded from http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf seemed to have been formatted with white text on a grey background. Maybe that's the version you need.
--Sam
Samuel Crow wrote:
Hello Paul,
The one I downloaded from http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf seemed to have been formatted with white text on a grey background. Maybe that's the version you need.
With adobe reader 8.1.4 I still get black text, and I think it's the
same one linked to in the development meeting list of presentations.
What pdf reader are you using?
Paul
Paul Melis wrote:
Samuel Crow wrote:
Hello Paul,
The one I downloaded from http://llvm.org/devmtg/2008-08/Begeman_EfficientJIT.pdf seemed to have been formatted with white text on a grey background. Maybe that's the version you need.
With adobe reader 8.1.4 I still get black text, and I think it's the
same one linked to in the development meeting list of presentations.
What pdf reader are you using?
Alright, tried opening the file with evince and now I can indeed read
the slides 
Paul
I'm using the version of Preview that came with MacOSX Leopard.