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>
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
On Tue, 2004-08-03 at 14:05, Vikram Adve wrote:> I have been at Microsoft the last couple of days and so couldn't > jointhe discussion earlier.No worries. I knew you'd chime in sooner or later :)> Here's my view of the name issue, and (thereason this is long), a > little about how I think we want users to viewthis tool:> > First, I think the name should convey the purpose of the tool ... > > Another possible name is llvmgen (even though I do think it should > have options to compile to native code). ... > > I would like to encourage users to think about the "normal" output of > our compiler as llvm code, not native code. There are many reasonsfor > 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 on-line (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.I hadn't considered this perspective and I agree. In fact, I agree to the point that I would consider naming the tools llvm-gen and llvm-run. That is, llvm-gen does whatever is necessary to completely or partially create a 100% LLVM (i.e. bytecode) executable. And, llvm-run (what you're calling llvmee) would do whatever is necessary to run and possibily re-optimize that program. That should be the normal and default behavior of the two tools. Since its also important for users to feel somewhat comfortable with their new toolkit, I think we should support an optional argument, possibly -native, that would cause llvm-gen to work towards a native executable instead of an LLVM executable.> For the name, again, I'd be happy with either llvmcd or llvmgen, witha > preference for the latter. The more important thing is to makellvm > code be the default output.I'm not thrilled with llvm-gen because it has overtones of "code generation" (which actually isn't far from the truth). But, it conjures up the wrong kind of tool .. something more like yacc or bison. However, I don't have any good alternatives in mind. I'll ponder some more. 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/8b052c31/attachment.sig>
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>
On Tue, 3 Aug 2004, Reid Spencer wrote:> > For the name, again, I'd be happy with either llvmcd or llvmgen, witha > > preference for the latter. The more important thing is to makellvm > > code be the default output. > > I'm not thrilled with llvm-gen because it has overtones of "code > generation" (which actually isn't far from the truth). But, it conjures > up the wrong kind of tool .. something more like yacc or bison. However, > I don't have any good alternatives in mind. I'll ponder some more.How about llvm-comp? -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/