Folks, I'm at the point in developing llvmc (Compiler Driver) where I need to get the details on the specific optimization arguments that the -O family of options should (by default) issue to "opt". I'm soliciting your feedback on this so I can start testing optimization. Hopefully you can provide it by early this coming week. For clarity, the -O options are currently defined as: -O0 - synonym for -O1 -O1 - options to speed up compilation, not execution -O2 - simple/fast module/function optimizations -O3 - aggressive module/function optimizations (as well as -O2) -O4 - simple/fast link time optimizations (as well as -O3) -O5 - aggressive link time optimizations (as well as -O4) What I'm looking for is a list of equivalent "opt" options for each of the five optimization levels defined above. This supports language front ends that don't do their own optimization (e.g. Stacker). Thanks, 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/20040814/df1d9c41/attachment.sig>
On Sat, 14 Aug 2004, Reid Spencer wrote:> I'm at the point in developing llvmc (Compiler Driver) where I need to > get the details on the specific optimization arguments that the -O > family of options should (by default) issue to "opt". I'm soliciting > your feedback on this so I can start testing optimization. Hopefully you > can provide it by early this coming week.Hrm, I don't really know that there is an absolute answer to this. Some experimentation will certainly be required.> For clarity, the -O options are currently defined as: > -O0 - synonym for -O1 > -O1 - options to speed up compilation, not executionI'm not sure what would be the best options, but at least -simplifycfg -mem2reg should be included.> -O2 - simple/fast module/function optimizationsProbably a subset of what gccas runs.> -O3 - aggressive module/function optimizations (as well as -O2)Everything that gccas runs?> -O4 - simple/fast link time optimizations (as well as -O3)Everything that gccas and gccld runs.> -O5 - aggressive link time optimizations (as well as -O4)For now, the same as -O3, but in the future, I'll add lots of neat stuff :)> What I'm looking for is a list of equivalent "opt" options for each of > the five optimization levels defined above. This supports language front > ends that don't do their own optimization (e.g. Stacker).gccas -debug-pass=Arguments will list the passes that are run by the tool. I don't know that there is a "right" list of options that should be put in. Just pick something and we can tune it over time. -Chris -- http://llvm.org/ http://nondot.org/sabre/
On Sat, 2004-08-14 at 21:00, Chris Lattner wrote:> On Sat, 14 Aug 2004, Reid Spencer wrote: > > > I'm at the point in developing llvmc (Compiler Driver) where I need to > > get the details on the specific optimization arguments that the -O > > family of options should (by default) issue to "opt". I'm soliciting > > your feedback on this so I can start testing optimization. Hopefully you > > can provide it by early this coming week. > > Hrm, I don't really know that there is an absolute answer to this.Yeah, I'm starting to realize this.> Some experimentation will certainly be required.Undoubtedly.> > > For clarity, the -O options are currently defined as: > > -O0 - synonym for -O1 > > -O1 - options to speed up compilation, not execution > > I'm not sure what would be the best options, but at least -simplifycfg > -mem2reg should be included.I was thinking -mergereturn and -instcombine might be okay too. I think Vikram suggested -instcombine. I added -mergereturn but I'm not sure that's right. Your thoughts?> > -O2 - simple/fast module/function optimizations > > Probably a subset of what gccas runs.My problem is that I don't know the passes well enough to know what a good subset is. I'll probalby know more after I read Muchnick.> > -O3 - aggressive module/function optimizations (as well as -O2) > > Everything that gccas runs? > > > -O4 - simple/fast link time optimizations (as well as -O3) > > Everything that gccas and gccld runs. > > > -O5 - aggressive link time optimizations (as well as -O4) > > For now, the same as -O3, but in the future, I'll add lots of neat stuff > :) > > > What I'm looking for is a list of equivalent "opt" options for each of > > the five optimization levels defined above. This supports language front > > ends that don't do their own optimization (e.g. Stacker). > > gccas -debug-pass=Arguments will list the passes that are run by the tool. > I don't know that there is a "right" list of options that should be put > in. Just pick something and we can tune it over time.Actually, I think I'm going to punt on this (sort of). What is appropriate for a given source language kinda depends on the source language to some extent. There will be some commonality (especially in the later, target specific, stuff) but rather than try to figure out the combinations now, I think I'm going to do just three things: 1. Allow the configuration file to specify a series of items that define which passes to run for a given level of optimization. This will support FE languages that don't have a compiler that does its own optimization and depends on "opt" to do it. So, for example, lang.opt1=-simplifycfg -instcombine -mem2reg could be specified as well as lang.opt2, lang.opt3 ... 2. Allow the configuration file to specify that a given tool understands the *intent* of the -On options and simply provide -On to that tool as a command line option, rather than attempt to list the equivalent set of pass names as options. This way the tool (typically a translator or optimization) can just use whatever is right without messing with the config file. So, instead of "lang.opt1" and friends the tool would use something like: translator.groks_dash_O=false optimizer.groks_dash_O=true which says we can't pass -On to the "translator" but we can pass it to the optimizer. 3. Default -O1 to be -simplifycfg, -instcombine, and -mem2reg just for utility and ease of use. Does this sound reasonable for a first cut? The config files could get a bit verbose, but the llvmc implementation becomes dead simple and there's significant flexibility for FE source language writers. Plus, I don't have to "guess" what the options should be :) 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/20040816/3fb88abe/attachment.sig>
Reid, I have one substantial change to suggest to this. I think the distinction between module-level and cross-module optimization is artificial and unnecessary in LLVM because transparent link-time optimization makes intra-module and cross-module optimizations indistiguishable. It *is* important to distinguish between fast and slow optimizations. Because of this, I would suggest a simpler scheme: -O0 and -O1 -- unchanged -O2 -- fast function-, module- and program-level optimizations -O3 -- aggressive (potentially slow) function-, module- and program-level optimizations A second important distinction that doesn't exist in LLVM today is between "always-safe" and "sometimes-unsafe optimizations." The latter class includes reordering optimizations on floating point code. We need to identify these and provide a flag to disable them all (in addition to the individual optimization on/off flags). In the near future, I think we should plan another flag for runtime optimization. It should *not* be just another level in the above list (like -O4) because it should be orthogonal to the above set of choices, i.e., you can combine runtime opt. with any level of development-time opt: -Oruntime -- transparent run-time optimization (or -Odynamic) --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Aug 14, 2004, at 7:25 PM, Reid Spencer wrote:> Folks, > > I'm at the point in developing llvmc (Compiler Driver) where I need to > get the details on the specific optimization arguments that the -O > family of options should (by default) issue to "opt". I'm soliciting > your feedback on this so I can start testing optimization. Hopefully > you > can provide it by early this coming week. > > For clarity, the -O options are currently defined as: > > -O0 - synonym for -O1 > -O1 - options to speed up compilation, not execution > -O2 - simple/fast module/function optimizations > -O3 - aggressive module/function optimizations (as well as -O2) > -O4 - simple/fast link time optimizations (as well as -O3) > -O5 - aggressive link time optimizations (as well as -O4) > > What I'm looking for is a list of equivalent "opt" options for each of > the five optimization levels defined above. This supports language > front > ends that don't do their own optimization (e.g. Stacker). > > Thanks, > > Reid. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2570 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040817/7382db9c/attachment.bin>
Hi Vikram, On Tue, 2004-08-17 at 09:01, Vikram Adve wrote:> Reid, > > I have one substantial change to suggest to this. I think > thedistinction between module-level and cross-module optimization > isartificial and unnecessary in LLVM because transparent > link-timeoptimization makes intra-module and cross-module > optimizationsindistiguishable. It *is* important to distinguish > between fast andslow optimizations. Because of this, I would suggest > a simpler scheme: > > -O0 and -O1 -- unchanged > -O2 -- fast function-, module- and > program-leveloptimizations > -O3 -- aggressive (potentially slow) function-, module- > andprogram-level optimizationsWell, it doesn't matter to me (simpler is better), but I think Chris and Misha (at least) will want to chime in on this. They had some pretty good reasons for having -O4 and -O5.> > A second important distinction that doesn't exist in LLVM today > isbetween "always-safe" and "sometimes-unsafe optimizations." > Thelatter class includes reordering optimizations on floating point > code. We need to identify these and provide a flag to disable them all > (inaddition to the individual optimization on/off flags).Makes sense.> > In the near future, I think we should plan another flag for > runtimeoptimization. It should *not* be just another level in the > above list(like -O4) because it should be orthogonal to the above set > ofchoices, i.e., you can combine runtime opt. with any level > ofdevelopment-time opt: > -Oruntime -- transparent run-time optimization (or -Odynamic)Yes, I agree. We originally had -O6 (simple runtime optimization) and -O7 (aggressive runtime optimization) which we dropped. For now, we're just punting on this issue because it doesn't exist yet. When the re-optimizer is in the main LLVM source tree, we can decide how we want to support it in llvmc but I think something like -Oruntime might be good. It would probably need to have additional parameters though (to specify the training input/load). Thanks for your thoughts, 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/20040817/7ce8fbbc/attachment.sig>