[LLVMdev] Preferring to use GCC instead of LLVM

[Gordon Henriksen]

On May 13, 2008, at 08:57, Jon Harrop wrote:

> Ok. There are lots of issues here. As I understand it, LLVM aims to:

Jon, I'm not sure where you got this list, but I don't find it  
accurate at all…

> . Support Mac OS first, Linux second and Windows is not a priority.
> . Provide JIT compilation first and the ability to generate  
> standalone executables and DLLs second.
> . Provide fast compilation first and optimization second.

To my estimation:

- Windows is not a priority only to the extent that there are fewer  
Windows developers using the framework. The *aim* is to be portable,  
and in fact LLVM does work on Windows. The project files are  
frequently out of date, though (since most development is done on  
Unix), so a Windows developer might be more interested in sticking to  
packaged releases. For comparison, I don't think the Xcode project  
files can even be used to build the system. :)

- Both static and JIT compilation are first-class. The most frequent  
use of LLVM is probably in Apple's OpenGL stack (JITC) but the most  
significant driver of development is as the back-end for llvm-gcc and  
clang (static compilation). That said, JIT support is weaker than  
static compilation in some areas (exceptions, GC).

- Both speed of compilation and speed of generated code are  
priorities. This is a dimension of flexibility afforded entirely to  
the user of the framework, selected by which transformations and  
analyses they choose to run, and at what time. If anything, however, I  
would argue that the design is skewed toward more optimal output;  
LLVM's compile times are never likely to be competitive in a streaming  
"MB machine code/s" race with low-overhead JIT compilers. I say this  
because it uses a complex bitcode format and a fairly expensive IR  
representation (lots of malloc objects). Both of which are explicitly  
tailored to analysis and low-overhead transformation—not streaming  
compilation performance. Likewise, there's lots of malloc traffic in  
the code generator, which (like the IR representation) is a non- 
optional component.

So I can't agree with the conclusions you draw, except that maybe  
kr512 might be better served elsewhere :)).

— Gordon