Re: LLVM

[David Chisnall]

On 1 Mar 2008, at 13:39, Andrew Pinski wrote:

> Sent from my iPhone

Didn't you say on the GCC list that you'd stopped using OS X?

> On Mar 1, 2008, at 5:25, David Chisnall <csdavec@swansea.ac.uk> wrote:
>
> > Most of the new 'features' of Objective-C 2.0 are in the compiler,  
> > rather than the runtime.  The few that need runtime support can get  
> > it from my runtime, which has a Self-like object model and provides  
> > a superset of the required functionality (the design goal was to  
> > support Io and Objective-C 2.0 in the same runtime).
>
> And my point is these runtime changes should just be added to the  
> gnu runtime.

Last time I posted libobjc patches to this list, you didn't reply.  I  
currently use a fairly modified version of the GNU runtime for Étoilé  
and have given up trying to get patches pushed upstream.  Any comments  
along the lines of 'the GNU runtime is maintained, and can support  
Objective-C 2.0 really!' sound hollow to me.  I have no objection to  
you using any of the code from my runtime in the GNU one - that's one  
of the many reasons why I went with a permissive license - but.

The GUN runtime was broken on FreeBSD for months last year because the  
threading code (30% of the entire codebase) is horrendous and relied  
on behaviour of the GNU linker.  I started trying to bring the GNU  
runtime up to the level of features that I wanted, and eventually  
decided that it would be less effort to start again.  The entire  
codebase for my runtime is significantly smaller than a diff updating  
the GNU one would have been.

Either way, the question of runtimes is orthogonal to the question of  
compilers.  My current work is adding support to clang for the GNU  
runtime.  After this, I will add support for my runtime.  If someone  
wants to add support for my runtime to GCC, then I'd be more than  
happy to provide assistance, but the code in GCC made me run away  
screaming.

Of course, if the GNU runtime remains GPL'd-unless-you-compile-with- 
the-FSF-compiler-otherwise-we're-taking-our-ball-and-going-home then  
there isn't much of an incentive to me to keep working on getting it  
supported.

> > I looked at adding support for it to GCC, but the GCC Objective-C  
> > code is about 10,000 lines of completely unreadable C and  
> > preprocessor macros mangled together.
>
> If you knew the history of this code you would blame the same person  
> who is writing clang. I guess everyone forgets that the objc front  
> was original written by Steve. I had hope to clean up the front-end  
> but never got around to it because I always had better things to  
> help out with inside GCC.

I am not judging people, I'm judging code.  The Objective-C code  
generation stuff in GCC is a mess (so is every other part of GCC I've  
looked at, but maybe I've just been unlucky with the parts I've seen  
and there's really some beautiful code in there somewhere).

The Objective-C code generation in clang does not exist.  This means  
that we have an opportunity to define the interfaces that will be  
useful to us.  All of the runtime-specific code in the clang tree at  
this date was written by me, and currently the only runtime supported  
is the GNU one.  If we work with the clang team now, we will be in a  
very good position to define where Apple have to put their code.

As I recall, the current mess in GCC comes from NeXT not wanting to  
play nicely with GCC and integrating the code tightly with their  
runtime to make it harder to compile without it.  Adding support for  
the GNU runtime happened later.

The clang code has a clean abstraction layer between the runtime- 
agnostic and runtime-specific parts.  This is a huge benefit for us,  
because it means that we can continue to support the GNU runtime and  
easily switch to others (the COLA one is also potentially  
interesting).  We can also keep our code generation parts up-to-date  
with whatever crazy things Apple does with the language[1] easily and  
benefit from all of the work they do.

> > LLVM supports x86, ARM, SPARC and PowerPC with experimental MIPS,  
> > Alpha and IA64 support.  What other platforms does GNUstep support?
>
> Let's see 68k, sh, hurd.

SuperH would be nice (probably required by the QuantumSTEP guys).  I  
don't see too many m68k machines around, and I've never seen one  
running GNUstep, but maybe they exist.  Although I note that NetBSD  
has packages for GNUstep-base 1.14 on i386, x86-64, SPARC, Alpha and  
PowerPC, while the m68k package hasn't been updated since 1.5.1  
(released March 2003).  HURD?  I can't imagine a HURD port would be  
too hard, since it's not a CPU architecture, and LLVM works on most  
other POSIXy platforms.

Looking at the release notes for LLVM, they seem to be adding platform  
support fairly quickly.  I wouldn't be surprised if m68K and SH get  
added soon.  Also, don't forget that it can emit pure C from any  
language and so if you have a C compiler for your target platform you  
can still benefit from the LLVM parsing and optimisation components.

> The ppc64 support is weak at best.

And yet, good enough to be used by Apple for compiling GLSL, and  
giving better performance than their hand-coded JIT.

> Debugging support is not really supported.

From what I've seen, LLVM now has quite nice support for debugging  
information, but it isn't yet

> Should I continue? I can go on and on. I guess I have anti-LLVM ever  
> since Chris and Apple started to spread FUD.

I'm seeing FUD flowing freely, but not from the Apple direction.

David

[1] If we want to.  If they're going to keep doing stupid things like  
breaking exceptions and deprecating (not supporting on 64-bit at all)  
posing then we might not want to.