[cfe-dev] libclang, someday?

Chris Lattner clattner at apple.com
Sun Aug 10 10:43:32 PDT 2008

On Aug 10, 2008, at 5:43 AM, Dan Villiom Podlaski Christiansen wrote:
> On 10 Aug 2008, at 14:12, Cédric Venet wrote:
>> 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  

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.


More information about the cfe-dev mailing list