[LLVMdev] list of LLVM optimization passes

Kenneth Hoste
Tue, 06 Jul 2010 15:56:08 -0000

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