[LLVMdev] list of LLVM optimization passes
Kenneth Hoste
kenneth.hoste at elis.ugent.be
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
>
More information about the llvm-dev
mailing list