From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25537 invoked by alias); 8 Apr 2004 21:16:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25433 invoked from network); 8 Apr 2004 21:16:06 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by sources.redhat.com with SMTP; 8 Apr 2004 21:16:06 -0000 Received: from caip.rutgers.edu (localhost [127.0.0.1]) by caip.rutgers.edu (8.12.9/8.12.9) with ESMTP id i38LG4mX008893; Thu, 8 Apr 2004 17:16:04 -0400 (EDT) Received: (from ghazi@localhost) by caip.rutgers.edu (8.12.9/8.12.9/Submit) id i38LG49P008892; Thu, 8 Apr 2004 17:16:04 -0400 (EDT) Date: Fri, 09 Apr 2004 20:06:00 -0000 From: "Kaveh R. Ghazi" Message-ID: <200404082116.i38LG49P008892@caip.rutgers.edu> To: jh@suse.cz Subject: Re: [PATCH]: Add some more builtins opts for sqrt/cbrt Cc: dave@hiauly1.hia.nrc.ca, gcc-patches@gcc.gnu.org References: <200404071456.i37Eu8iY002799@hiauly1.hia.nrc.ca> <200404071617.i37GHbOH026431@caip.rutgers.edu> <20040408210137.GC3299@kam.mff.cuni.cz> X-SW-Source: 2004-04/txt/msg00523.txt.bz2 Message-ID: <20040409200600.xnhqjSrsIyiGSHBkzoZKzvWPE4TGRlqE2n78muRANng@z> > From: Jan Hubicka > > > Yes, I know about this one. See > > http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02216.html > > > > The discussion died off waiting for an explanation from Jan about > > mathfn_built_in. > > Sorry, I must've missed the thread completely :( > And even now I can't find any question regarding mathfn_built_in in > the thread. It is supposed to return for given function and type > equivalent of function operating on the type. The question, as posed by rth in the thread here: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02277.html is why in mathfn_built_in are we comparing the mode rather than type-main-variant? Consider the transformation: cbrtl(sqrtl(x)) -> powl(x,1/6) When using mathfn_built_in on a system where the sizes of double and long double are the same, your algorithm will prefer the double version of the function and return plain pow even though we asked for the long double variant. Was there a reason to write mathfn_built_in this way? E.g. did you prefer the double type because you were trying to support pre-c99 systems and did it this way before TARGET_C99_FUNCTIONS was introduced? If we have no reason to keep the mathfn_built_in algorithm this way, I'd like to change it to return predictable values regardless of the sizes of the FP types on the target. Thanks, --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu