[LLVMdev] Compiler Driver Decisions

[John Criswell]

Chris Lattner wrote:
> 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.

I don't believe this is realistic.  This is a configuration file that 
tells the driver how to compile stuff.  There is a definite chance that 
it will need to be modified as parts of the compiler are updated, 
replaced, or removed.

Think of installing a new frontend.  It would be nice if its 
installation could automatically insert itself into the driver's 
configuration file.

Or how about writing a program that prints the compiler's configuration 
to stdout?

Or an administrator who wants to write a quick program to re-configure 
the compiler on several different machines he administrates?

I think we have two choice to make these operations convenient.  Either 
we provide command line tools for modifying the configuration, or make 
the file's format in such a way that these tools can be easily and 
accurately written by others on an on-demand basis.

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

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