[cfe-dev] libclang, someday?

[Chris Lattner]

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  
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.

-Chris