[LLVMdev] Compiler Driver Decisions

[John Criswell]

Dear All,

I thought I would chime in with some ideas and opinions:

o Configuration Files

If it isn't too much trouble, I think we should go with XML for the 
following reasons:

1) We wouldn't need to implement a parsing library.  There are several 
XML parsing libraries available, and I'm guessing that they're available 
in several different programming languages (Reid, am I right on that?).

2) It makes it easier for other programmers to write tools that read, 
modify, and/or write the configuration file correctly.  If my assumption 
about XML libraries being available in several different languages is 
correct, then that means we don't need to write a library for each 
language that people want to use.

3) I believe it would keep the format flexibile enough for future 
expansion (but again, Reid would know better here).

Having configuration files that can be manipulated accurately is 
important for things like automatic installation, GUI's, configuration 
tools, etc.

o Object Files

I've noticed that there's a general agreement that we should not 
encapsulate LLVM bytecode files inside of another object format (such as 
ELF).  However, I'd like to pose a few potential benefits that 
encapsulation in ELF might provide:

1) It may provide a way for standard UNIX tools to handle bytecode files 
without modification.  For example, programs like ar, nm, and file all 
take advantage of the ELF format.  If we generated LLVM ELF files, we 
wouldn't need to write our own nm and ar implementations and port them 
to various platforms.

2) It could mark the bytecode file with other bits of useful 
information, such as the OS and hardware on which the file was generated.

3) It may provide a convenient means of adding dynamic linking with 
other bytecode files.

4) It may provide a convenient place to cache native translations for 
use with the JIT.

Here are the disadvantages I see:

1) Increased disk usage.  For example, symbol table information would 
duplicate the information already in the bytecode file.

2) Automatic execution.  Ideally, if I have a bytecode executable, I 
want to run it directly.  On UNIX, that is done with #!<interpreter>.  I 
believe ELF provides similar functionality (where exec()ing the file can 
load a program or library to do JIT compilation), but if it doesn't, 
then we lose this feature.

o Compiler Driver Name

I'd vote for either llvmcc (llvm compiler collection) or llvmcd (llvm 
compiler driver).  To be more convenient, we could call it llc (LLvm 
Compiler) or llcd (LLvm Compiler Driver).  Calling it llc would require 
renaming llc to something else, which might be appropriate since I view 
llc as a "code generator" and not as a "compiler" (although both terms 
are technically accurate).

Generally, I recommend keeping the name short and not using hyphens 
(because it's slower to type them).

o Optimization options

I agree with the idea of using -O<number> for increasing levels of 
optimization, with -O0 meaning no optimization.  It's a pretty intuitive 
scheme, and many Makefiles that use GCC use the -O option.

-- John T.

-- 
*********************************************************************
* John T. Criswell                         Email: criswell at uiuc.edu *
* Research Programmer                                               *
* University of Illinois at Urbana-Champaign                        *
*                                                                   *
* "It's today!" said Piglet. "My favorite day," said Pooh.          *
*********************************************************************