This is the mail archive of the
mailing list for the GCC project.
Re: GCSE store motion
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 15 May 2002 10:01:49 -0700
- Subject: Re: GCSE store motion
- References: <Pine.LNX.firstname.lastname@example.org>
--On Wednesday, May 15, 2002 10:45:31 AM -0600 Roger Sayle
> Hi Mark,
>> If the optimization makes the compiler go slower when compiling
>> itself, it ain't worth having.
> You'll also appreciate that Hennesy and Patterson's pitfalls and
> fallacies on the existance of "typical applications".
> The only example of store motion that I'm aware of comes from glibc
> source code containing an __asm__ statement. Inline assembly language
> is pretty rare in the GCC source code, but that would be a poor reason
> not to support it. Dan's analysis of SPEC should perhaps of included
> the timings of disabling GCC's optimizations after the Linux kernel
> and GLibC had been rebuilt without what could be a system performance
> critical transformation.
Dan's claim seems to be that nobody has a real-world application that
shows an improvement with store motion enabled. If that's true, we
don't need that optimization enabled. We can keep the code, and use
it when it becomes more useful, but there's no reason to be running
If, however, someone has real applications that show measurable
improvents -- the Linux kernel would certainly qualify -- then we
should rethink the issue.
Over the past few years, there's a perception that we've had a bad
tendency to make the compiler slower by adding nice optimizations that
don't actually make programs faster, but sometimes do make them buggier.
We need to combat that problem by vetting new optimizations.
> I don't use a GCC bootstrap to judge floating performance either :>
Of course. :-)
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com