From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80158-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15097 invoked by alias); 30 Jul 2003 15:56:56 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 15086 invoked from network); 30 Jul 2003 15:56:55 -0000
Received: from unknown (HELO steven.lr-s.tudelft.nl) (62.234.23.175)
  by sources.redhat.com with SMTP; 30 Jul 2003 15:56:55 -0000
Received: from steven.lr-s.tudelft.nl (localhost.localdomain [127.0.0.1])
	by steven.lr-s.tudelft.nl (8.12.8/8.12.8) with ESMTP id h6UFwuh7012245;
	Wed, 30 Jul 2003 17:58:56 +0200
Received: (from steven@localhost)
	by steven.lr-s.tudelft.nl (8.12.8/8.12.8/Submit) id h6UFwuTB012243;
	Wed, 30 Jul 2003 17:58:56 +0200
X-Authentication-Warning: steven.lr-s.tudelft.nl: steven set sender to s.bosscher@student.tudelft.nl using -f
Subject: Re: std::pow implementation
From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>
Cc: Gabriel Dos Reis <gdr@integrable-solutions.net>,
   Scott Robert Ladd <coyote@coyotegulch.com>,
   Alexandre Oliva <aoliva@redhat.com>, gcc@gcc.gnu.org
In-Reply-To: <Pine.LNX.4.44.0307301751060.561-100000@goofy>
References: <Pine.LNX.4.44.0307301751060.561-100000@goofy>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1059580736.3642.117.camel@steven.lr-s.tudelft.nl>
Mime-Version: 1.0
Date: Wed, 30 Jul 2003 16:24:00 -0000
X-SW-Source: 2003-07/txt/msg02208.txt.bz2

Op wo 30-07-2003, om 17:52 schreef Richard Guenther:
> > It is no surprise that inlinig with no proper constant propagation and
> > dead code elimination does not produce better code.
> 
> I think this statement is way too harsh, as cprop and dce are quite good
> with gcc - apart from some special cases such as your std::pow(T, int)
> implementation (for which we need to blame the loop unroller, not cprop
> or dce).

True, but it happens too late for languages that build functions as
trees and inline trees.  One of the reasons why the inline limits have
been fairly low, was that expand would consume huge amounts of time, and
I've seen PRs for functions that blew up to as much as 1GB.

BTW Another reason was quadratic behavior in other parts of the compiler
(was it the scheduler???).

Gr.
Steven