On 02 Feb 2007 20:27:45 +0100, Soeren Sandmann <[EMAIL PROTECTED]> wrote: > "Leen Toelen" <[EMAIL PROTECTED]> writes: > > > We'll start with what the heck LLVM does, and go from there. > > > > - LLVM <http://www.llvm.org/> is a fascinating compiler system that > > optimizes code at many stages, from compile-time to run-time > > optimizations; > > e.g., your code is optimized while it's still running! > > I have actually been looking at LLVM lately. Some quick notes from me > playing around with it: > > - It is an excellent compiler that generates really good machine code > (on x86 at least). > > - It supports vector code, aka SIMD instructions. It supports at least > SSE and 3D-now. The vector code generated is good.
I haven't spent the time to actually analyze the output. I'm just curious: did you? How did you come to this conclusion? (that the vector code generated is good) > > - It can be retargeted with a flexible machine description language > (flexible enough to do something sensible with x86) > > - The input you give it is an SSA graph where all the temporaries have > explicit types such as 'int' or 'vector4x16'. Generating code for > the Render operations (and the core operations for that matter) in > this language looks very much doable. Yes, I've been thinking the same thing myself. I'm in the early stages of planning a CCG-based dynamic code generation approach to the Render operations. At this point, I'm just getting familiar with CCG, but I think I'll spend some time investigating LLVM, too. VCODE is on my list to check out, too. I would love to hear any advice this list would have for me in this endeavor (speeding up Render operations via dynamic/static code generation, beyond traditional C compiler-based approaches). Once advantage CCG or VCODE would have over an LLVM-based approach is that they are much more lightweight than any LLVM-based approach (mostly because they do a lot less). Lightweight wrt memory use and CPU use. CCG is just amazing in this respect. LLVM has going for it a large community and maturity far beyond CCG or VCODE. Plus, it seems that generating shader code would be difficult in CCG or VCODE, which brings me to... > - I haven't investigated this in detail, but I don't see any reason > LLVM couldn't be retargeted to GPU shaders (which are more or less > SIMD instructions anyway). This is pretty cool, too. AFAIK, Apple's Core Image Kernel language is just a subset of GLSL that is compiled to LLVM bytecode which is then optimized and transformed to SIMD or a shader language (they might go straight to shader assembly here, who knows) depending on the available hardware. Makes a lot of sense. > - It is written in C++ with STL, which among other things means the > binaries of the compiler itself are huge. As an example, a simple > Hello World jit compiler was over 3MB of text, which included 470 > copies of some copy_backwards_iterator() function. This may > obviously be a problem for embedded systems, but even on desktop > systems such a huge binary is going to use a lot of CPU cache. Or you just don't ship the compiler. So, if we throw out the dynamic code generation idea, and just try to generate at build-time all the specialized Render code, we wouldn't need it, right? In this way we would be using LLVM for automatically optimizing the SIMD/shader code (beyond what gcc can do with C+intrinsics), and perhaps more importantly, using LLVM to automatically generate specialized code for each operation + extend mode + format + etc. Currently, one has to manually write a lot of code (for each platform) to get the same coverage. On the other hand, it's likely that the iPhone is using / will use LLVM, which would support the idea that the size of LLVM isn't such a big deal, even on embedded platforms. > So I think it's definitely worthwhile looking into LLVM some more. Agreed. Dan _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
