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