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>