[LLVMdev] Compiler Driver Decisions

[Chris Lattner]

On Tue, 3 Aug 2004, Vikram Adve wrote:
> First, I think the name should convey the purpose of the tool --
> otherwise, it just creates a confusing acronym (and goodness knows we
> have enough names already, even though most of them are clear).

Yes, I totally agree.

> Unfortunately this leads me to vote against llvmcs -- it's vague and
> (worse) a misnomer.  A "system" to a program or a compiler driver or an
> invoker or anything specific like that.  *LLVM* is a system; this
> program is a program with a more limited purpose.  Of the list below,
> llvmcd comes closest to describing what this tool does.

I don't like llvmcs either, though I don't know of a good name.  The
problem is that we are entering the realm of LLVM as a *compiler* not as a
bunch of utilities for building compilers.  As such, the compiler driver
(which is an LLVM tool) is really the users interface to a C or C++ or
Java compiler.  As such, they don't want to think of it as a compiler
driver, they want to think of it as THE compiler.  When we say 'gcc foo.c'
we are actually invoking the GCC compiler driver, though we name it 'gcc'.

This is part of why it is critical to have a good name :).  Note however,
that it may be perfectly reasonable to just name the tool llvm-driver or
something, then have individual compilers built from LLVM install symlinks
into /usr/bin.  Given that, they could call themselves whatever they want,
while still invoking llvm-driver.

> I would like to encourage users to think about the "normal" output of
> our compiler as llvm code, not native code.  There are many reasons for
> this but here are two key ones:

I agree, we definitely want to support this, but we also want to be able
to support traditional static compilation as well.  In particular, there
should be some flag (-native?) or something that you can give to the
compiler to direct it to produce a native executable.

-Chris