Mail Archives: djgpp/1998/09/23/12:30:28
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/
- Raw text -