[LLVMdev] Compiler Driver Decisions

[Reid Spencer]

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>