[LLVMdev] list of LLVM optimization passes

Tue Jul 6 08:56:08 PDT 2010

On Jul 6, 2010, at 5:04 PM, Manuel Llosa wrote:

> Dear Kenneth, I see. Do you plan sharing your framework in open source?
> For now, I will continue using ctuning tools (they support LLVM as is but not 
> some specific things on JIT dynamic recompilation what is my thesis about). 
> I will like to compare all tools of course and will be happy
> to share results although real not until autumn).Look forward
> to your results and hopefully keep in touch.

I haven't gotten to sharing my framework, mostly because it's pretty messy.
It works fine on my end, but getting it in a state that would allow others to use
it is a lot of work. That's research tools for you. ;-)

You should look into some of my papers, in particular the ones at CGO-2008
and CGO-2010 (see my website, http://www.elis.ugent.be/~kehoste).

K.

> Regards!
> 
> Manuel
> 
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kenneth Hoste
> Sent: Tuesday, July 06, 2010 4:50 PM
> To: Manuel Llosa
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] list of LLVM optimization passes
> 
> 
> On Jul 6, 2010, at 10:09 AM, Manuel Llosa wrote:
> 
>> Dear Kenneth, May I ask you if you are implementing your search within 
>> ctuning framework: ctuning.org/ctuning-cc?
> 
> No, I'm not. I've built my own framework, and since I don't have any experience with the
> ctuning framework, I don't intend to start using that. There's little gain in it for me.
> 
>> The thing is that I use it since some time for my thesis to optimize code size and
>> compilation time and run time with GCC though they are not using genetic algorithms
>> but some slower hybrid of random exploration and than AI with some fronteer detection. 
>> Since recent version can be working with other compilers then GCC and has some support for LLVM 
>> so I have thought to improve this support and compare both GCC and LLVM. But if you are extending that
>> tool now, I do not want to duplicative work so could you tell me please for how long it can take because I 
>> can wait for your extensions. I want to compare this multi-objective modes for GCC 4.5 and LLVM 2.7
>> for many flags and will want to put experiments in their database for everyone to see if it is works ...
> 
> Since it doesn't support LLVM as is, that motivates me even more to stick with my own framework.
> 
> Good luck with your experiments, I'd love to see some results when you have them.
> 
> greetings,
> 
> Kenneth
> 
>> Regards!
>> 
>> Manuel
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kenneth Hoste
>> Sent: Sunday, July 04, 2010 4:19 PM
>> To: llvmdev at cs.uiuc.edu
>> Subject: [LLVMdev] list of LLVM optimization passes
>> 
>> Hello LLVMers,
>> 
>> I'm putting together some (extensive) experiments with using a genetic algorithm to construct sets of optimization
>> passes that are as close as optimal in a number of ways, e.g. compilation time, execution time, code size, ...
>> 
>> I've figured out which LLVM tools I should use for this (llvm-gcc to obtain bitcode, opt to optimize, llc to obtain assembly, ...),
>> and I'm now looking into which optimization passes I should take into account in my experiments.
>> 
>> First, one thing that is not entirely clear to me: do analysis passes result in additional information being made available
>> to other passes, e.g. does "-domtree" enable more aggressive optimization being done by other passes?
>> In other words, should I consider some analysis passes in my setup, and if so, which ones?
>> 
>> Initially, I just used the set of 58 'transform' passes listed at [1].
>> Unfortunately, it turns out that this list if not up to date. Below are my findings, comparing [1] to "opt -help".
>> 
>> If someone can clarify the points below, I'll try and put together a patch for [1], resolving the inconsistencies...
>> 
>> Several transform passes listed at [1] are no longer supported by the opt tool:
>> 
>> 	-indmemrem 
>> 	-insert-block-profiling 
>> 	-insert-function-profiling 
>> 	-insert-null-profiling-rs 
>> 	-insert-rs-profiling-framework 
>> 	-lowerallocs
>> 
>> Is assume this is known? Were these passes removed recently?
>> 
>> 
>> A large number of passes mentioned in "opt -help" are not mentioned in [1]:
>> 
>> 	-abcd 
>> 	-always-inline 
>> 	-functionattrs 
>> 	-insert-optimal-edge-profiling 
>> 	-instnamer 
>> 	-iv-users 
>> 	-lazy-value-info 
>> 	-lda 
>> 	-libcall-aa 
>> 	-live-values 
>> 	-mergefunc 
>> 	-partial-inliner 
>> 	-partialspecialization 
>> 	-pointertracking 
>> 	-print-dbginfo 
>> 	-print-dom-info 
>> 	-profile-estimator 
>> 	-profile-verifier 
>> 	-sccvn 
>> 	-scev-aa 
>> 	-simplify-libcalls-halfpowr 
>> 	-split-geps 
>> 	-ssi 
>> 	-ssi-everything 
>> 	-strip-debug-declare 
>> 	-strip-nondebug 
>> 
>> It's unclear to me which of these passes are transform passes, and which ones are analysis passes.
>> If someone here can point out the transform and analysis passes for me, I can try and come up with a
>> patch for [1].
>> 
>> greetings,
>> 
>> Kenneth
>> 
>> 
>> [1] http://llvm.org/docs/Passes.html
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 