Are you aware of the ccc script and/or llvmc2 (I think there is a version
for clang, otherwise it should be pretty easy to do)?
Also, I may be wrong, but clang is more like cc1/cc1plus that gcc since this
is just the front end, or even less than these. For exemple the -O flags
don't do much sense for clang, but they will be usefull for opt.
I think the idea is to have llvmc2 be the equivalent of gcc.
Based on a loose “feeling” from trying it on my 1.25GHz G4, I'd say ccc about twice as slow as using clang directly. I'm not familiar with llvmc2, I'm afraid. In my the driver with clang retains it's main selling point, speed, and has the potential to increase usage significantly.
I consider the current design to be a temporary measure. Ultimately, I would like to have a single executable that roughly corresponds to 'cc1' in GCC. This would include option parsing for most of the options cc1 accepts as well as linking in the LLVM optimizer and backend.
I haven't measured, but I suspect that a significant part of the slowness of ccc is having to emit llvm ir, then pipe it into opt, then pipe it into llc. This is a lot of needless I/O. The big reason that I haven't done this yet is that it will slow down link time of the clang executable, which reduces turn-around time for clang tests. It also encourages people to write clang regtests that grep native .s files or something.
Perhaps a solution to this is to leave Clang design the way it is (just a front-end) and add the extra options where it makes sense. Then we could introduce a new tool that links in the clang front-end pieces as well as the llvm backend pieces. We could even drop this into a separate svn module or something so it doesn't get built by default. If we had this tool, ccc/llvmc would end up being a simple driver like the GCC driver (a wrapper around cc1, as, and ld but not much more).
Moving forward, I'd like to avoid the forking/exec'ing inherent in the common driver interface we have today. That means something like llvmc2 would be linked into the clang tool executable, and itself used as a library, except instead of fork/exec'ing cc1, it would just call into the 'clang cc1' directly. This isn't on my short-term priority list (just getting clang to work reliably ranks higher :), but will eventually be interesting.
Besides, is a reason for the main clang executable to be so incompatible? Of the many things clang is, one is a C/Objective-C compiler. Having one executable, included with clang and installed by default, that works as a drop in replacement for gcc, cc or another C-compiler is very useful indeed. For one thing, it could allow the many Autoconf/Automake/Make/configure based projects to easily try clang and report any bugs they find.
Yes, this would be nice. Right now, ccc fills this role, but it could be improved.
In this regard, accepting and ignoring -O* is crucial, as most other C compiler accept them.
Of course, we just don't want to link in the optimizers yet.