[LLVMdev] Re: gcc4 or gcc3?

[Hendrik Boom]

On Mon, 07 Aug 2006 11:45:04 -0700, Reid Spencer wrote:

> Hi Hendrik,
> 
> On Mon, 2006-08-07 at 14:35 -0400, Hendrik Boom wrote:
>> I just downloaded the CVS version of llvm and llvm-test.  Presumably
>> this is the one that's scheduled to become 1.8 in a few days.
> 
> Not really. The current CVS head is quite a ways past release 1.8 at
> this point. If you want to get the release 1.8 preview, please check out
> the release_18 branch:
> 
> cvs co -rrelease_18 llvm
> 
>> 
>> (1) To install llvm, do I really need the llvm version of the gcc front
>> end? I have no special interest in yet another c/c++ conmpiler.
> 
> No, you can build LLVM without it. Some functionality will be disabled,
> however (like the test cases for C/C++).
> 
>> 
>> (2) If I need llvm gcc, will the binary version suffice, or do I need
>> to compile the CVS version?
> 
> Binary version should be okay.
> 
>> (3) If I need its source code, does it properly fit within the
>> llvm/projects directory, just like the test suite?  And it that where I
>> should execute the cvs co, like like the test suite?  Or is it so
>> independent that I should put it totally elsewhere in the file
>> system?
> 
> It's independent, put it somewhere else :)
> 
>> (4) The page http://llvm.org/docs/GettingStarted.html#checkout says to get
>> the gcc 3.4 source code.
> 
> The link above is for accessing llvm-gcc3 which was based on gcc 3.4
> source code. 
> 
>> The instructions to compile it in http://llvm.org/docs/CFEBuildInstrs.html
>> seem to deal in gcc 3 and gcc 4 instead.  Is this an error in the
>> documentation, or does it indicate that I should compile the llvm-gcc 3.4
>> source code with GNU's gcc versions 3 or 4 depending on what;'s already
>> installed on my system.
> 
> No, its not an error. Perhaps what you're misunderstanding is that there
> are two versions of llvm-gcc. The first, which we call llvm-gcc3, is
> based on gcc 3.4 and you can get that via CVS or release tarball.  THe
> second version, which we call llvm-gcc4, is based on gcc 4.0.1 and is
> maintained by Apple.

In a paper called something like "slim binaries" a few years ago, the
author claimed that they were more efficient than conventional
machine-level executables.  That they consisted of was extremely compact
intermediate code.  Apparently the time taken to generate machine code
from the intermediate code was dwarfed by the time that would have been
taken to read the executable machine code from disk (slow I/O and all
that).  What's more, storing the intermediate code took a lot less space
than the machine code, so it was a win there, too.  Now the compression
techniques they used were quite dependent on the details of the source
language they used (Oberon), so it's not clear how much these techniques
translate to other systems.   But it's quite possible that the technique
could be quite effective for a company that has to make its software
run compatibly on multiple architectures.  It's certainly something I've
considered, and llvm seems a useful tool for building it.

I believe the guy that did the slim binaries trademarked the name, but as
far as I know has done nothing with it since.  I've  tried to email him
unsuccessfully.

> They were nice enough to provide a subversion repository to access it.
> In general, LLVM is slowly transitioning to using the llvm-gcc4 front
> end. Currently its missing a couple features (most notably exception
> handling in C++, compile time optimization), but in general it is
> already easier to deal with because it works just like GCC and doesn't
> require an llvm-based run-time library.  These deficiencies will most
> likely get corrected in the near future (probably by the end of the year
> or sooner). At that time, we'll probably deprecate llvm-gcc3 (release
> 1.10?) and just use llvm-gcc4.
> 
> Note: this email contains forward-looking statements that I don't want
> to be held accountable for, so read it with a grain of salt.  :)
> 
> Reid.