From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31089 invoked by alias); 16 Mar 2010 15:50:17 -0000 Received: (qmail 30836 invoked by uid 48); 16 Mar 2010 15:49:57 -0000 Date: Tue, 16 Mar 2010 15:50:00 -0000 Message-ID: <20100316154957.30835.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dominiq at lps dot ens dot fr" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg01496.txt.bz2 ------- Comment #39 from dominiq at lps dot ens dot fr 2010-03-16 15:49 ------- > Especially on embedded targets with soft-float the multiplication would > add a significant code size penalty. Even in this case this would strongly of the code. It may be true if other pieces require log and exp. If not I seriously doubt that replacing the code for multiplies and square roots will be larger than the code for log and exp. My (very limited) understanding of this issue is that at some point x*sqrt(x) is replaced with pow(x,1.5) (so that pow(x,a)*pow(x,b) is optimized as pow(x,a+b)). So even if the programmer write x*sqrt(x) (s)he can end up with pow(x,1.5), resulting in poor performances in term of both speed and size (not speaking of accuracy). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106