On Mon, 2 Aug 2004, Reid Spencer wrote:> I have a very simple XML document type that I use for configuring XPS > systems. There's only four elements and it follows much the same kind of > grouped name/value pairs that Chris is suggesting. Chris' example would > be like: > <configuration name="llvm"> > <group name=".c"> > <item name="compile">cc1 %in -o %out</item> > <item name="optimize">gccas %in -o %out.bc</item> > <!-- ... --> > </group> > </configuration> > > I think something like this satisfies all the goals: > * simple and easy; recursive descent parser is a no-brainer > * XML format with full DTD (RNG or XML Schema) that can be used by other > tools to auto-configure llvmcs > * structured so we can extend in the futureOkay, if you get all of the benefits without the cost, go for it :) -Chris> On Mon, 2004-08-02 at 22:22, Chris Lattner wrote: > > On Tue, 3 Aug 2004, Bill Wendling wrote: > > > I admit a bias here: I've worked with MS style INI files. They didn't > > > leave a good impression with me. However, they do fit the bill for a lot > > > of applications. What do you envision a typical INI file to look like? > > > > I was thinking of something simple like this: > > > > [.c] > > > > compile = cc1 %in -o %out > > optimize = gccas %in -o %out.bc > > link = gccld ... > > > > [.cpp] > > > > compile = cc1plus %in -o %out > > ... > > > > etc. Something like that. The exactly details are still very much up in > > the air, but just simple key/value pairs is all we should need. > > > > -Chris > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/
Some additional responses (this covers multiple previous messages):> As part of my work on bug 353: Create Front End Framework And Compiler > Driver (http://llvm.cs.uiuc.edu/PR353), I'm starting a discussion on > the > design and requirements of the compiler driver.Thanks very much for taking the lead on this, Reid. I think this will prove to be a valuable thing and, as you noted, the primary interface to LLVM for the end-user.>> >>> Additionally, we should have options to: >>> * generate analysis reports ala the LLVM analyze tool >> >> I'm not certain how useful this would be. It would add complexity to >> the >> driver that is of arguable use. If anything I would make this the >> last >> priority: the people who use 'analyze' are compiler developers, not >> end >> users. > > True, I'll drop it.Good decision. I agree with Chris that this driver should not try to do things outside the normal "compile-link-optimize[-codegen]" sequence. Similarly, llvmee should control the "[codegen-]run-reoptimize" sequence.>> Certain common GCC options should be supported in order to make the >> driver appear familiar to users of GCC. In particular, the following >> options are important to preserve:I agree, and your list looked good. Some other options to consider are: -save-temps Do not delete intermediate files -time Time the execution of each subprocess -B <directory> Add <directory> to the compiler's search paths -b <machine> Run gcc for target <machine>, if installed Some of our current tool options may also need to be in driver: -time-passes Time individual LLVM passes -stats Print pass statistics>> In >> particular, this would require all users to change their makefiles to >> get >> IPO/lifelong optzn support from LLVM, violating one of the main goals >> of >> the system.Yes!>> I don't think that anything should change w.r.t. the contents of .o >> files. >> In particular, .o files should contain LLVM bytecode without wrappers >> or >> anything fancy around them. >> ... >> Personally I don't see a problem with this. We already have "llvm >> aware" >> replacements for many system tools, including ld, nm, and a start for >> ar. >> These tools could be made 'native aware', so that 'llvm-ld x.o b.o' >> would >> do the right thing for mixed native and llvm .o files.I agree.>> Okay, you answered my question above. Perhaps you can define the >> specific passes that should be included n -O0. > > I would thinking -constprop -simplifycfg -mem2reg -dce, though that's > just a first thought :)Also, -instcombine?> >>> llvmgcc X.c -On -S # "no" optimization, emit a 'raw' .ll file > >> That's fine, -On, I suppose is basically "absolutely no optimization >> passes"-On seems misleading to me. It conveys opt. level "n" . It could also be read as "on" (as opposed to "off"). How about -Onone? As Chris pointed out, this is really meant for compiler developers, not end-users, so let's make it different from the standard user's scheme and clear to boot.> <configuration name="llvm"> > <group name=".c"> > <item name="compile">cc1 %in -o %out</item> > <item name="optimize">gccas %in -o %out.bc</item> > <!-- ... --> > </group> > </configuration> > > I think something like this satisfies all the goals: > * simple and easy; recursive descent parser is a no-brainer > * XML format with full DTD (RNG or XML Schema) that can be used by > other > tools to auto-configure llvmcs > * structured so we can extend in the futureReid, while I see the power and extensibility of this, it seems way overkill for what the driver will do. The driver should not be replacing Makefiles, which are the way to orchestrate a complex multi-step build. The driver really only ever needs about five steps as you described above. We shouldn't need an extensible markup language to specify compile = <string> optimize intra-module = <string> link = <string> optimize cross-module = <string> codegen = <string> XML would make sense if we were trying to configure the pass manager's internal operations or customize the running of IPO passes in opt, or something like that, which may have multiple complex steps. The driver is the end-user's interface to the llvm system and should err on the side of simplicity, not power. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4729 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040803/45b75101/attachment.bin>
On Tue, 3 Aug 2004, Vikram Adve wrote:> >> Okay, you answered my question above. Perhaps you can define the > >> specific passes that should be included n -O0. > > > > I would thinking -constprop -simplifycfg -mem2reg -dce, though that's > > just a first thought :) > > Also, -instcombine?Sure. When the time comes, we should do some timings to figure out which passes speed up the compiler. instcombine could be one of those.> >>> llvmgcc X.c -On -S # "no" optimization, emit a 'raw' .ll file > > > >> That's fine, -On, I suppose is basically "absolutely no optimization > >> passes" > > -On seems misleading to me. It conveys opt. level "n" . It could also > be read as "on" (as opposed to "off"). How about -Onone? As Chris > pointed out, this is really meant for compiler developers, not > end-users, so let's make it different from the standard user's scheme > and clear to boot.Great point, I agree. -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/
On Tue, 2004-08-03 at 14:53, Vikram Adve wrote:> Some additional responses (this covers multiple previous messages): > > Thanks very much for taking the lead on this, Reid. I think this will > prove to be a valuable thing and, as you noted, the primary interface > to LLVM for the end-user.No problem. Happy to do it. I don't mind improving the edges while your research crew makes the core better. In the end we all end up with a better system.> I agree, and your list looked good. Some other options to consider > are: > -save-temps Do not delete intermediate files > -time Time the execution of each subprocess > -B <directory> Add <directory> to the compiler's > searchpaths > -b <machine> Run gcc for target <machine>, if installedYes, good points. I'll put these on the list.> Some of our current tool options may also need to be in driver: > -time-passes Time individual LLVM passes > -stats Print pass statisticsYes, those are givens.> Also, -instcombine?Okay.> -On seems misleading to me. It conveys opt. level "n" . It could > also be read as "on" (as opposed to "off"). How about -Onone? As > Chris pointed out, this is really meant for compiler developers, not > end-users, so let's make it different from the standard user's scheme > and clear to boot.Chris and I were debating what -On, -O0 (oh zero) and -O1 were supposed to mean. The defs of -O0 and -O1 got kinda muddles. I think we should drop the idea of -On* and just use -O0 to mean "absolutely no optimization". The default, -O1, would give the "light/fast optimization" described previously. Since -O0 is somewhat strange, it reinforces the notion that this option is for front end developers to use when checking the output of their front end.> > > <configuration name="llvm"> > <group name=".c"> > <item name="compile">cc1 %in -o %out</item> > <item name="optimize">gccas %in -o %out.bc</item> > <!-- ... --> > </group> > </configuration> > > I think something like this satisfies all the goals: > * simple and easy; recursive descent parser is a no-brainer > * XML format with full DTD (RNG or XML Schema) that can be > used byother > tools to auto-configure llvmcs > * structured so we can extend in the future > > Reid, while I see the power and extensibility of this, it seems way > overkill for what the driver will do. The driver should not be > replacing Makefiles, which are the way to orchestrate a complex > multi-step build. The driver really only ever needs about five steps > as you described above. We shouldn't need an extensible markup > language to specify > compile = <string> > optimize intra-module = <string> > link = <string> > optimize cross-module = <string> > codegen = <string> > XML would make sense if we were trying to configure the pass manager's > internal operations or customize the running of IPO passes in opt, or > something like that, which may have multiple complex steps. The > driver is the end-user's interface to the llvm system and should err > on the side of simplicity, not power.While I tend to agree (my first thought was Windows .ini files), some good points were raised on IRC. First, other tools (e.g. IDEs like Eclipse) will more naturally be able to parse/generate XML and integration with those tools is important. Secondly, its not at all clear to me that the configuration can be as simple as you've described above. I think we can make the configuration file extremely simple even if its XML (i.e. only four element names and one attribute name). By choosing XML we don't have to worry about completely changing the format should it need to get a little more complicated. However, what I'd like to do is defer the decision on this until I've gotten through the feature/design document and its been reviewed. The details of what goes in a configuration file will be much more clear at that point and the correct format will most likely present itself. 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/25feaaa0/attachment.sig>