This is the mail archive of the 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

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?


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