[LLVMdev] Optimization Levels - Need The Details

Chris Lattner sabre at nondot.org
Mon Aug 16 13:38:54 PDT 2004


On Mon, 16 Aug 2004, Reid Spencer wrote:
> 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?

-mergereturn isn't really an optimization, it's a pass that can be used by
other passes (like adce).  -instcombine is a reasonable idea, though I
don't know if it would be faster to run it than not.

> > > -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.

Sure, but you don't have to come up with the "one true answer" :)

> 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 ...

Sounds good.

> 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.

Sounds great.

> 3. Default -O1 to be -simplifycfg, -instcombine, and -mem2reg just for
>     utility and ease of use.

Sounds good.

> 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 :)

Yup!

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/




More information about the llvm-dev mailing list