[LLVMdev] Optimization Levels - Need The Details

[Reid Spencer]

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>