From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-92434-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25478 invoked by alias); 10 Mar 2004 16:06:11 -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 25470 invoked from network); 10 Mar 2004 16:06:09 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 10 Mar 2004 16:06:09 -0000
Received: from localhost (localhost [127.0.0.1])
	by nile.gnat.com (Postfix) with ESMTP
	id 8ABB0F2E1A; Wed, 10 Mar 2004 11:06:06 -0500 (EST)
Received: from nile.gnat.com ([127.0.0.1])
 by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 20238-01-2; Wed, 10 Mar 2004 11:06:06 -0500 (EST)
Received: from gnat.com (hoosic.gnat.com [205.232.38.102])
	by nile.gnat.com (Postfix) with ESMTP
	id 3A4E2F2E19; Wed, 10 Mar 2004 11:06:06 -0500 (EST)
Message-ID: <404F3D04.2050208@gnat.com>
Date: Wed, 10 Mar 2004 16:06:00 -0000
From: Robert Dewar <dewar@gnat.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Roger Sayle <roger@eyesopen.com>, gcc@gcc.gnu.org,
	"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Subject: Re: Question on valid transformations for cbrt
References: <Pine.LNX.4.44.0403070640560.29012-100000@www.eyesopen.com> <0564E1F0-72A8-11D8-98DF-000A95A4DC02@kernel.crashing.org>
In-Reply-To: <0564E1F0-72A8-11D8-98DF-000A95A4DC02@kernel.crashing.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at nile.gnat.com
X-SW-Source: 2004-03/txt/msg00515.txt.bz2

Segher Boessenkool wrote:

>> The problem with cbrt, unlike sqrt, is that its is more expressive than
>> pow.  i.e. cbrt(-29.7) = -3.1 but pow(-29.7,1.0/3.0) => EDOM.  Hence
>> we can't normalize cbrt(x) as pow(x,1.0/3.0),
> 
> 
> You can "normalize" cbrt(x) as  sign(x) * pow(abs(x), 1.0/3)  -- maybe that
> helps some further optimizations?

Of course both these transformations are numerically horrible. I trust 
that this is understood.

>> but we can safely go the
>> other way pow(x,1.0/3.0) => cbrt(x).

Well I don't like transformations like this which change the computation
so radically and give completely different results. This is not real
arithmetic, and the compiler really has no business making 
substituations that are not meaning preserving.