[cfe-dev] libclang, someday?
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
>> 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
>> 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
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
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
> 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