Hi Kenneth,

Just found your post in the gcc archive ;) - wanted to say that there have been 
many projects 
on the topic of optimal compiler flag selections. Actually, there are several 
free and commercial 
tools available for several years already: PathOpt from PathScale and ESTO from 
IBM, for example.
We switched to PathOpt in 2003 and currently use it for our research since it 
is 
easily configurable, works with any languages, does not require project 
modifications and
has many extendable basic search strategies (random, one by one, all but one). 
We easily 
coupled it with the PAPI library to obtain hardware counters, retargeted it to 
work with GCC
and Intel Compilers, and added different machine learning algorithms. 

If you are interested, you can find more information about these tools and 
search techniques 
on global and fine-grain level, including publications and links to groups 
working on iterative 
optimizations at my webpage here:
http://fursin.net/research_iter.html

Also, if you are interested, we will present our new paper "Rapidly Selecting 
Good Compiler
Optimizations using Performance Counters"
at the CGO in a few days where we use hardware counters and machine learning to 
select best
optimization flags for the PathScale compiler (Open64/ORC compiler). 
Unfortunately, I will
not be able to come to CGO and present it due to some passport problems, but 
there will be 
my colleagues whom you can chat with about iterative optimizations ...

By the way, we now move most of our tools and techniques to the GCC within 
MilePost project 
and HiPEAC network, and would be happy for any comments and suggestions.
Our development website is here:
http://gcc-ici.sourceforge.net

Cheers,
Grigori

=====================================
Grigori Fursin, PhD
Research Fellow, INRIA Futurs, France
http://fursin.net





    * From: Kenneth Hoste <kenneth dot hoste at ugent dot be>
    * To: Diego Novillo <dnovillo at redhat dot com>
    * Cc: gcc at gcc dot gnu dot org, Ben Elliston <bje at au1 dot ibm dot com>
    * Date: Wed, 7 Feb 2007 15:35:15 +0100
    * Subject: Re: which opt. flags go where? - references
    * References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Hi,

On 07 Feb 2007, at 15:22, Diego Novillo wrote:

    Kenneth Hoste wrote on 02/07/07 08:56:

        [1] Almagor et al., Finding effective compilation sequences (LCES'04)
        [2] Cooper et al., Optimizing for Reduced Code Space using Genetic 
Algorithms (LCTES'99)
        [3] Almagor et al., Compilation Order Matters: Exploring the Structure 
of the Space of
Compilation Sequences Using Randomized Search Algorithms (Tech.Report)
        [3] Acovea: Using Natural Selection to Investigate Software Complexities
(http://www.coyotegulch.com/products/acovea/) 

    You should also contact Ben Elliston (CC'd) and Grigori Fursin (sorry, no 
email).

    Ben worked on dynamic reordering of passes, his thesis will have more 
information about it.

    Grigori is working on an API for iterative an adaptive optimization, 
implemented in GCC. He
presented at the last HiPEAC 2007 GCC workshop. Their presentation should be
    available at http://www.hipeac.net/node/746


I actually talked to Grigori about the -Ox flags, I was at the HiPEAC 
conference too ;-) I didn't
include references to his work, because my aim wouldn't be at reordering of 
passes, but just
selecting them. I understand that reordering is of great importance while 
optimizing, but I think
this project is big enough as is.

        Some other questions:
        * I'm planning to do this work on an x86 platform (i.e. Pentium4), but 
richi told me that's
probably not a good idea, because of the low number of registers available on 
x86. Comments? 

    When deriving ideal flag combinations for -Ox, we will probably want common 
sets for the more
popular architectures, so I would definitely include x86. 


OK. I think richi's comment on x86 was the fact that evaluating the technique 
we are thinking about
might produce results which are hard to 'port' to a different architecture. But 
then again, we won't
be stating we have found _the_ best set of flags for a given goal... Thank you 
for your comment.


        * Since we have done quite some analysis on the SPEC2k benchmarks, 
we'll also be using them
for this work. Other suggestions are highly appreciated. 

    We have a collection of tests from several user communities that we use as 
performance
benchmarks (DLV, TRAMP3D, MICO). There should be links to the testers somewhere 
in
http://gcc.gnu.org/ 


OK, sounds interesting, I'll look into it. In which way are these benchmarks 
used? Just to test the
general performance of GCC? Have they been compared to say, SPEC CPU, or other 
'research/industrial'
benchmark suites (such as MiBench, MediaBench, EEMBC, ...) ?


        * Since there has been some previous work on this, I wonder why none of 
it has made it into
GCC development. Were the methods proposed unfeasible for some reason? What 
would be needed to make
an approach to automatically find suitable flags for -Ox interesting enough to 
incorporate it into
GCC? Any references to this previous work? 

    It's one of the things I would like to see implemented in GCC in the near 
future. I've been
chatting with Ben and Grigori about their work and it would be a great idea if 
we could discuss this
at the next GCC Summit. I'm hoping someone will propose a BoF about it. 


I'm hoping my ideas will lead to significant results, because I think this is 
an important issue.

greetings,

Kenneth

--

Statistics are like a bikini. What they reveal is suggestive, but what they 
conceal is vital (Aaron
Levenstein)

Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste



    * References:
          o which opt. flags go where? - references
                + From: Kenneth Hoste
          o Re: which opt. flags go where? - references
                + From: Diego Novillo

Index Nav:      [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:    [Date Prev] [Date Next]         [Thread Prev] [Thread Next]

Reply via email to