This is the mail archive of the
mailing list for the GCC project.
Re: GCSE store motion
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery 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 11:08:40 -0600 (MDT)
- Subject: Re: GCSE store motion
Ok. I concede. I'm all for disabling and even deleting optimizations
that have no real world effect. I wouldn't be surprised if store
motion rarely applied even to large real world examples that made
heavy use of __asm__ (such as glibc and linux). Current store motion
is probably only catching the holes in GCC's CSE and GCSE cprop anyway.
> 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.
But, you'll also remember from disabling builtins in g++ for v3.0x, that
tight release schedules lead to pieces of code being disabled rather than
fixed (despite the performance loss), and that code that is atleast
exercised infrequently is less likely to bitrot than code paths that are
To summarise, I agree with everyone, now that we're all aware of what
the real issues are. Perhaps, PR opt/5200 should be closed or given a
testcase to avoid any further confusion?