This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Add some more builtins opts for sqrt/cbrt


 > From: Jan Hubicka <jh@suse.cz>
 > 
 > > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]