[LLVMdev] Compiler Driver Decisions

[Chris Lattner]

On Wed, 4 Aug 2004, John Criswell wrote:

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

So that's the tension: with XML, there are lots of off-the-shelf tools
that you can use to parse it.  OTOH, this should be an extremely trivial
file that does not need any parsing per-say.  Unless there is a *clear*
advantage to doing so, we should not replace a custom 20 LOC parser with a
gigantic library.

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

I don't buy this at all.  In particular, these files are provided by
front-end designers for the sole consumption of the driver.  NO other
tools should be looking in these files, they should use the compiler
driver directly.

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

You can do this with any format you want, just include an explicit version
number.

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

Again, none of these tools should be using these files.

> o Object Files

... Misha did a great job responding to these ...

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

For native translation caching, we will just emit .so files eventually.
It is no easier to attach a .so file to an existing ELF binary than it is
to attach it to a .bc file.  Also, we probably *don't* want to attach the
cached translations to the executables, though I'm sure some will disagree
strenuously with me :)  In any case, this is still a way out.

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

The problem is that -O0 does *not* mean no optimization.  In particular,
with GCC, -O0 runs optimizations that reduce the compile time of the
program (e.g. DCE) that do not impact the debuggability of the program.
Making the default option be -O1 would help deal with this, but I'm still
not convinced that it's a good idea (lots of people have -O0 hard coded
into their makefiles).  *shrug*

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/