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/
On Wed, 2004-08-04 at 10:08, Chris Lattner wrote:> > 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*I don't see why we have to maintain 100% compatibility with GCC. We're so incompatible in so many other ways that I don't see it as a necessity. For example, we probably won't have all the -f and -X and -W options that GCC does. So, why can't we just DEFINE the optimization levels and be done with it? Its not like users of LLVM can just use their existing makefiles, they will have to make some adjustments. Also, I don't know of very many people that use -O0. Typical usage is either no -O option on the command line or -O2, -O3. In those typical use cases the driver will give them basically what they expect. So I propose: -O0 = zero optimization, raw output from the front end -O1 = default fast/lightweight optimization, emphasis on making compilation faster -O2 = moderate/standard optimization that make significant improvements in generated code but don't take significant computation time to optimize -O3 = aggressive optimization, regardless of computation time with the effect of producing the fastest executable -O4 = life-long optimization, includes -O3 but also profiles and re-optimizes 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/20040804/491b994d/attachment.sig>
On Wed, Aug 04, 2004 at 12:16:12PM -0700, Reid Spencer wrote:> So I propose: >[snip]> -O3 = aggressive optimization, regardless of computation time with the > effect of producing the fastest executableI would suggest splitting -O3 into 2 or more levels of optimization, because as written, -O3 sounds pretty scary: "regardless of computation time", and given some people who thing that several minutes of compile time is acceptable, I think it's useful to split it into "aggresive opt", "aggresive interprocedural opt", and "aggressive interprocedural analysis with interprocedural opt". -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
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. * *********************************************************************
On Wed, 4 Aug 2004, Reid Spencer wrote:> I don't see why we have to maintain 100% compatibility with GCC. We're > so incompatible in so many other ways that I don't see it as a > necessity.We are? Currently you can just 'configure CC=llvmgcc' and stuff works.> For example, we probably won't have all the -f and -X and -W > options that GCC does. So, why can't we just DEFINE the optimization > levels and be done with it? Its not like users of LLVM can just use > their existing makefiles, they will have to make some adjustments.They currently don't have to make these changes. The -f flags that don't make sense we can just ignore. We support all of the -W flags I think.> Also, I don't know of very many people that use -O0. Typical usage is > either no -O option on the command line or -O2, -O3. In those typical > use cases the driver will give them basically what they expect.I agree this is much more common.> So I propose: > > -O0 = zero optimization, raw output from the front end > -O1 = default fast/lightweight optimization, emphasis on > making compilation fasterThat is fine, but my point is that NO USER will ever care about -O0. Since this is the case, why expose it at all? It should only be exposed for LLVM compiler hackers, which is why I suggested -On (later ammended to -Onone). I would not have a problem with it really being named something without a -O prefix (-really-give-me-what-the-front-end-spits-out). Given that, either -O0 and -O1 should do the same thing, or we should drop one. -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/
On Wed, 4 Aug 2004, John Criswell wrote:> > 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.Yes, exactly. But this is strictly for communication between the front-end and the compiler driver, nothing more, nothing less. We want the driver to be able to evolve without the front-ends having to be upgraded. As such, we could just have a version number if needed.> Think of installing a new frontend. It would be nice if its > installation could automatically insert itself into the driver's > configuration file.It would just add a fixed file to a directory, not modify any existing files.> Or how about writing a program that prints the compiler's configuration > to stdout?llvm-driver -print-compiler-configuration> Or an administrator who wants to write a quick program to re-configure > the compiler on several different machines he administrates?You're missing the point. The driver is the interface to the program, not these text files.> 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.No, if people are trying to do these things, it is a sign that we have done something fatally wrong. -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/