[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