I keep running into cases where some program crashes clang with -O1 but
not -O, or vice versa.
Why are these different? What's the difference? If I were a normal
programmer which would I want to use?
Thanks,
John
IIRC -O maps to -O2.
-Eli
Hi all,
We are looking to try and reduce the size of the clang and LLVM
libraries and were wondering if anyone had any advice on how to do this.
All we want is to be able to compile from a single language to a single
back-end and for that back-end to emit instructions; we don't care about
anything else. Currently we are building LLVM to use only our target, so
that is OK. Is it possible to build clang with support for only one
language? Or does anyone else have any tips about how to reduce the size
of the libraries?
Thanks for your help,
Rob
Hi Rob,
There is no way to compile Clang to support only one language right
now, and it would probably provide only a marginal size win. Your best
place to focus attention is on pieces of the LLVM backend that you
don't need. For example, I added support for reading LLVM files
directly which added in the asmparser library, but you can get
eliminate that (with some code editing, we don't currently have any
support for conditionalizing these things).
Note that compiling with Clang or llvm-gcc, especially at -Os, will
also give a pretty major code size improvement.
- Daniel
The best way to shrink the clang bits themselves are to subset out things like the static analyzer, the rewriter and other non-compiler things that are linked into the binary.
-Chris
Hi all,
We are looking to try and reduce the size of the clang and LLVM
libraries and were wondering if anyone had any advice on how to do this.
All we want is to be able to compile from a single language to a single
back-end and for that back-end to emit instructions; we don't care about
anything else. Currently we are building LLVM to use only our target, so
that is OK. Is it possible to build clang with support for only one
language? Or does anyone else have any tips about how to reduce the size
of the libraries?
If you don't use plugins, dropping the --export-dynamic should help.
Thanks for your help,
Rob
Cheers,
Hi Robert,
Try removing intrinsics you don't need. In particular in Intrinsics.td you
can comment out some of the includes at the bottom of the file.
Cheers,
Nicolas
Is that really going to make a significant difference?
I've been looking at the same issue, in my case trying to make a
simple JIT (using only LLVM at the time, not trying to use clang to
parse and then JIT, but rather deserializing bytecode and JIT it).
I made the simplest example I could based on my limited knowledge of
the interfaces, and even linking with -dead_strip and optimizing for
size it's still 1.25MB+. If I add any optimization passes (InstCombine
in particular seems to pull in a lot of code), the static code size
(in the text section) balloons up past 4MB. (This is all on Mac OS
using g++ to compile; on Windows using VC, compiling for size and
using /OPT:REF,ICF, the result is around 30% smaller).
Two things I noticed:
- Though I've configured for only x86_64, I get both 32-bit and 64-bit
code generation support according to llc --version; I don't know how
much overhead having 32-bit support is, but I really want to make the
smallest JIT possible, so excluding that would be nice.
- Although I only care about JITting, the execution engine interface
seems to pull in code for interpreting as well; I haven't verified
that this is the absolutely the case, but it seems to make a dynamic
choice and looking at the code I would assume the interpreter is
getting pulled in.
I've watched Nate Begeman's excellent talk from 2008 on making a fast
JIT (as well as the talk on implementing OpenCL, which goes over the
same points). I'm wondering if anyone has advice on making a fast
*small* JIT as well.
Thanks,
Mark