This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Optimize pow(x,0.0) = pow(1.0,y) = 1.0
- From: Roger Sayle <roger at www dot eyesopen dot com>
- To: Tim Josling <tej at melbpc dot org dot au>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 21 Feb 2003 14:27:04 -0700 (MST)
- Subject: Re: [PATCH] Optimize pow(x,0.0) = pow(1.0,y) = 1.0
> This patch adds quite a lot of code to GCC. The extra tests will be
> executed many times for expressions which are not degenerates of the
> form x**0 or 1**x, thereby burning CPU cycles, imcreasing work set
> size, etc.
In the C programming language, there are two approaches to adding more
code to a program that have no impact on the typical path, and therefore
will not slow the compiler down. The first is adding additional cases
to a "switch" statement, and the second is providing an alternate
pointer to function, much like the virtual methods available in C++.
This patch follows the first strategy and extends an existing "switch"
statement, so if the source code doesn't call "pow", and the inserted
basic block/functions don't split hot blocks into separate cache lines
there should be almost no effect on typical performance.
Optimizations of pow, exp and log are common in many optimizing
compilers. For example, both of the transformations in my patch are
performed by the OpenWatcom compiler. These functions are also
common in numerical benchmarks, including whetsone and bytemark.
Whilst I understand the current concern with compiler performance,
some of the "witch hunts" are begining to exceed the bounds of
common sense. The first test for a scapegoat is that it is far
easier to slow down the compiler with a patch that contains a
loop (or deep call stack), than it is for a patch that doesn't.
[Mathematical proof left to the reader :>].