Hi, all.
I've watched Steve's and Ted's developer meeting talks, and they both
seem like invitations for developers to build tools and checks of all
kinds on top of the clang libraries. Obviously, if these tools and
checks are generic enough, I'm sure that they would be welcome for
inclusion within the clang project itself. But what about the others?
Is a relatively stable API a long-term goal?
Thanks,
Sam Bishop
I think that clang will evolve to the same point that LLVM is at: most of the API is stable in LLVM, but there are occasional big changes. For a really stable API, it would be interesting to make C or scripting language bindings that we try real hard to never change.
-Chris
On a similar note, how settled are you on the current command line interface to clang? I can't help but find it somewhat annoying that the current interface is wholly incompatible with GCC and, I suspect, other compilers. I patched it locally to support -c, -S and -Wall, to ignore valid -O flags, as well as allow -W and -Wextra as aliases for -Wall. Are you interested in changes like these?
Other possible improvements would be a refactoring to use -f* and -m* like GCC. Also, it would be nice if the clang executable was able to link objects, emit native code, and defaulted to outputing a.out.
(Re-post as I sent from the wrong address previously.)
Did you find ccc script under utils directory inadequate? It supports
-c, -E, -o, ignore -W and -O, link objects, emit native codes, default
to a.out, and in general quite compatible with GCC.
On a similar note, how settled are you on the current command line
interface to clang? I can't help but find it somewhat annoying that the
current interface is wholly incompatible with GCC and, I suspect, other
compilers. I patched it locally to support -c, -S and -Wall, to ignore
valid -O flags, as well as allow -W and -Wextra as aliases for - Wall.
Are you interested in changes like these?Other possible improvements would be a refactoring to use -f* and -m*
like GCC. Also, it would be nice if the clang executable was able to
link objects, emit native code, and defaulted to outputing a.out.
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.
Regards,
Cédric
Sam Bishop wrote:
Hi, all.
I've watched Steve's and Ted's developer meeting talks, and they both
seem like invitations for developers to build tools and checks of all
kinds on top of the clang libraries. Obviously, if these tools and
checks are generic enough, I'm sure that they would be welcome for
inclusion within the clang project itself. But what about the others?
Is a relatively stable API a long-term goal?
Even with an unstable API, it is advantageous to start building tools with Clang, since at this early stage it will be much easier to influence the design of Clang, than when a stable API is introduced.
-Argiris
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.
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.
In this regard, accepting and ignoring -O* is crucial, as most other C compiler accept them. It's even somewhat standardised and required for the UNIX c99 executable. [1] Likewise, having to use a separate linker or filter out -Wall is annoying. It would be very nice if the goal of source-level compatibility with GCC was extended to also include invocation and supported flags.
[1] Single UNIX Specification v. 3: <c99
ccc works with Autotools, etc. So I guess your main complaint is that
it is slow. Any patch to speed it up will be appreciated.
ccc is an interim measure; long term solution would be llvmc2. Any
improvement to that would be also appreciated.
If llvmc2 is compatible with GCC command line (or UNIX cc), I don't
see why clang should also be compatible. As far as I can tell clang's
command line is designed to export clang's functionality in the most
direct manner (like AST serialzation, etc.)
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.
It seems strange, but I never used ccc. The overhead of the script should be
small, except if your source file are very small...
I'm not familiar with
llvmc2, I'm afraid.
llvm\tools\llvmc2
there is a start of configuration for clang in examples, which would need to
be expended.
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.
This executable can be build by configuring llvmc2. See the doc and
In this regard, accepting and ignoring -O* is crucial, as most other C
compiler accept them. It's even somewhat standardised and required for
the UNIX c99 executable. [1] Likewise, having to use a separate linker
or filter out -Wall is annoying. It would be very nice if the goal of
source-level compatibility with GCC was extended to also include
invocation and supported flags.
Clang is only a frontend, not comparable to gcc. The driver llvmc should be
compatible and can be easily be made so. But I think no one took the time
yet.
Regards,
Cédric
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