From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14496 invoked by alias); 17 Oct 2003 09:24:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14488 invoked from network); 17 Oct 2003 09:24:49 -0000 Received: from unknown (HELO mx3.informatik.uni-tuebingen.de) (134.2.12.26) by sources.redhat.com with SMTP; 17 Oct 2003 09:24:49 -0000 Received: from juist (semeai [134.2.15.66]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 75E8B144; Fri, 17 Oct 2003 11:24:47 +0200 (DFT) Received: from falk by juist with local (Exim 3.36 #1 (Debian)) id 1AAQqj-0007g5-00; Fri, 17 Oct 2003 11:24:45 +0200 To: Scott Robert Ladd Cc: gcc mailing list Subject: Re: Compiler Analysis: 3.3, 3.4, or tree-ssa? References: <3F8D50D5.1020401@coyotegulch.com> From: Falk Hueffner Date: Fri, 17 Oct 2003 11:48:00 -0000 In-Reply-To: <3F8D50D5.1020401@coyotegulch.com> Message-ID: <87ptgwkyhu.fsf@student.uni-tuebingen.de> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (cabbage) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00714.txt.bz2 Scott Robert Ladd writes: > A couple months ago, I gave a preliminary report on my project to > analyze the effectiveness of gcc optimizations via an evolutionary > algorithm. At that time, the responses I received lead me to spend > time reworking my research code into soemthing a bit more formal and > modular. Interestingly, I did something similar just this week. My attempt was pretty half-assed though, just a small Python script. In each generation, it keeps the best 16 and creates 16 new by crossover of two random others. The genome is based only on bits, which is also not so great, because I end up with stuff like "-mmemory-latency=12 -mmemory-latency=256 -mmemory-latency=3". Still, I got some interesting results, e. g., all of the fittest individuals have "-mno-bwx", which for this test case (gzip) is probably the option I would have bet to have the *worst* possible effect (it turns off byte access instructions on Alpha). Overall, I could improve run time on my gzip test case from 10s at -O3 to 9.3s. I tried the tree-ssa branch; I also got lots of ICEs, especially with -fnew-ra (but that was already filed long ago), and when combining -fno-expensive-optimizations with disabling loop optimizations (PR12628). Is your framework available somewhere? I'd be interested in comparing the methods... -- Falk