Re: Connect The Dots: iPhone Graphics, OS X, LLVM, ARM, and Ruby?

["Daniel Amelang" <daniel amelang gmail com>]

On 02 Feb 2007 20:27:45 +0100, Soeren Sandmann <sandmann daimi au dk> wrote:
> "Leen Toelen" <toelen gmail com> 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