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
Dear Kenneth, May I ask you if you are implementing your search within ctuning framework: ctuning.org/ctuning-cc? 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 ... 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
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 >