[LLVMdev] Compiler Driver Decisions

[Reid Spencer]

On Tue, 2004-08-03 at 18:13, Chris Lattner wrote:

> > 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'.
> 
I agree with this, but ..

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

.. not with this. I don't want to force compiler writers to have to make
yucky symlinks to llvm-driver. Also, I think it would be good for all
involved if they could think of LLVM (via their use of the driver) as
this magic black box that just gets compilation done, regardless of the
languages involved.  Otherwise they will have to remember the weird
names used by all the language developers for all the different language
compilers. I'd rather hide that complexity from the user and just
provide them with a one-stop tool that does LLVM compilation.  Its also
very useful for language developers to just "slot in" a new version of
the front end with appropriate configuration tools and the driver never
has to change. 

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

As I said in my last message, I think the default behavior should be
that the driver works towards executing LLVM bytecode (in whatever way
appropriate) and we provide the -native option for those that want to
force the driver to produce native executables (but not native object
files!)

Reid.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040803/d86a2d94/attachment.sig>