From: "John S. Fine" Newsgroups: comp.os.msdos.djgpp Subject: Re: Optimizations Date: Wed, 23 Sep 1998 12:08:53 -0400 Lines: 56 Message-ID: <36091D15.6B94@erols.com> References: Reply-To: johnfine AT erols DOT com NNTP-Posting-Host: 207-172-240-171.s44.as3.bsd.erols.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Eli Zaretskii wrote: > > On Mon, 21 Sep 1998, John S. Fine wrote: . . . > > All of my routines in the entire project have side effects. > > Then you cannot expect GCC to be clever about optimizing loops that > call these functions. Perhaps rewriting some of them to avoid side > effects is something you could consider. I never said I wanted GCC to be clever about the function calls. In fact, in the examples I posted with GCC generating terrible code, the only function call wasn't even in a loop. In my real code, there are function calls in most loops and those function calls have side effects, because having those side effects happen in the loop is the main purpose of the loop. I think it is clear that the function calls have little to do with the bad code, because the bad code was generated even when I removed the function calls. I would hope GCC could be "clever" about local variables, even in loops and even across function calls. I do not take the address of those local variables in any way and I know GCC knows that it can manipulate local variables whose address is never taken, in ways it couldn't if the address were taken. That includes the fact that no subroutine's side effects can legitimately affect a local variable whose address is never taken. I would hope GCC could recognise when it can't be clever about static variables. In most of my code, GCC copies static variables to a register, then copies the register to stack space, then copies the stack space to a different register, then uses that register just once and in a way that would have been equally easy with a direct reference to the static variable. Overall, GCC optimizes better than any other C compiler I have used; However, I still find many of its gross failures confusing, and I was hoping there was a practical way to avoid them. I have tried all those switches you suggested, with the expected results (changing any of them from the -O2 values made worse overall code). -fno-force-mem fixed every gross example of anti-optimization that I saw in my code. Unfortunately, it also removed almost all of the real optimizations as well, resulting in worse code. It is a shame that GCC can't look at the results of each individual application of that feature and notice when it is harmful rather than helpful. For my current project, I guess I need to abandon the goal of having a high performance 486 version and a portable C version in the same source code (which would have helped long term maintenance). It will be much easier to simply write the 486 version in assembler. -- http://www.erols.com/johnfine/ http://www.geocities.com/SiliconValley/Peaks/8600/