llvm dev - Aug 2004 - [LLVMdev] Optimization Levels - Need The Details

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 execution
I'm not sure what would be the best options, but at least -simplifycfg
-mem2reg should be included.
> -O2 - simple/fast module/function optimizations
Probably 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 optimizations
Well, 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>