This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compiler Analysis: 3.3, 3.4, or tree-ssa?
- From: Falk Hueffner <falk dot hueffner at student dot uni-tuebingen dot de>
- To: Scott Robert Ladd <coyote at coyotegulch dot com>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 17 Oct 2003 11:24:45 +0200
- Subject: Re: Compiler Analysis: 3.3, 3.4, or tree-ssa?
- References: <3F8D50D5.1020401@coyotegulch.com>
Scott Robert Ladd <coyote@coyotegulch.com> 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