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: Obvious expand_builtin_mathfn improvement installed


Hi Zack,
> > Could you be a little clearer about this bug, and why your patch
> > affects it?
>
> THere is already Roger's fix waiting in the queue to be reviewed, but
> apparently Richard is taking a break...

I believe Jan owes Richard an apology :>  The patch to avoid revaluation
of the arguments to built-in functions has already been reviewed and
applied to mainline CVS.

http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02916.html
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02933.html

This is why probably why Jan writes "Recently the tree is changing
rapidly", and also why a recent patch of Jan's that included an early
version of my fix to builtins.c failed to apply cleanly.


As for the patch itself, its no longer required to fix any of Jan's
regressions, but it is a useful optimization.  I didn't include the
CODE_FOR_nothing optimization (as suggested by Jan) in my patch,
because its unclear whether optabs.c may try implementing a mathematical
function by widening the mode, to use an intrinsic available only in a
wider mode.  For example, implementing sqrtsf2 using sqrtdf2 as in
(float)sqrt((double)x).  If widening of floating point modes is
allowed/advantageous, checking whether the builtin intrinsic is
available in the original mode may miss cases where a platform's
floating point hardware only provides instructions for doubles, etc...

[In theory, x86 only provides math functions on long doubles, but
we currently lie to optabs, by duplicating these functions for all
floating point modes].

Roger
--


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