This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCSE store motion




--On Wednesday, May 15, 2002 10:45:31 AM -0600 Roger Sayle 
<roger@eyesopen.com> wrote:

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

Right.

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

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                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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