[LLVMdev] Optimization Levels - Need The Details

[Reid Spencer]

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>