[LLVMdev] Compiler Driver Decisions

[Vikram Adve]

I have been at Microsoft the last couple of days and so couldn't join 
the discussion earlier. Here's my view of the name issue, and (the 
reason this is long), a little about how I think we want users to view 
this tool:

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

Another possible name is llvmgen (even though I do think it should have 
options to compile to native code).  This fits slightly better with my 
view of how users should view the compilation process in LLVM (but 
llvmcd is ok too).

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:

(1) Most compilations are run one or several files at a time, so 
interprocedural optimizations cannot be done when running the compiler 
driver.  Modern compilers present a misleading view that front-ends 
generate object code.  That's not true at higher levels of optimization 
but users never realize that -- front-ends really generate some kind of 
IR file that is read by the link-time whole-program optimizer.  We can 
avoid this confusing view by making llvm output the "normal" and 
default case.

(2)  Once the dynamic optimizer Brian and Tanya and Anand have worked 
on is ready for distribution, I would like to make llvmee (Misha's llvm 
execution environment) the expected, default way to run llvm programs.  
The llvm driver (llvmcd or llvmgen or whatever name we pick) would 
generate llvm code that is later compiled and run transparently by 
llvmee.  Whether the code generation to native code happens offline 
(via llc) or online (via the jit) can be controlled via llvmee.  Again, 
this requires reinforcing the view that shipped programs are in llvm 
form, not native form.

Note that none of this prevents people from using the driver to 
generate native code in one step.  But the tool names and default 
behavior should convey our view of what is important about LLVM.  I 
think we *don't* want users to view llvm as just another standard 
source-to-native code compiler.

For the name, again, I'd be happy with either llvmcd or llvmgen, with a 
preference for the latter.   The more important thing is to make llvm 
code be the default output.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

On Aug 3, 2004, at 12:32 PM, Misha Brukman wrote:

> On Tue, Aug 03, 2004 at 12:26:50PM -0500, Brian Gaeke wrote:
>>> On Mon, Aug 02, 2004 at 06:05:16PM -0700, Reid Spencer wrote:
>>>> On Mon, 2004-08-02 at 18:04, Chris Lattner wrote:
>>>> llvmcd - llvm compiler driver
>>>> llvmci - llvm compiler invoker
>>>> llvmcs - llvm compiler system (or perhaps "compilation system")
>>>> llvmct - llvm compiler tool
>>>> llvmx  - llvm eXecutive
>>>
>>> I like llvmcs.  Contrary to the IRC discussion, I am not sure I want
>>> a hyphen in this ... Without a hyphen, it could still be the
>>> compiler system, with the hyphen, I'd say almost definitely computer
>>> science. :)
>>
>> I'm happy with llvmcs or llvmcc.
>
> I also notice that cs has the double-meaning of llvm.cs[.uiuc.edu] or
> just simply llvm.cs, i.e., LLVM implemented in C#. :)
>
> -- 
> Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3939 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040803/5b0d63e7/attachment.bin>