Add internal math functions

[Richard Sandiford]

Thanks for the review.

Jeff Law <law@redhat.com> writes:
> On 11/07/2015 05:30 AM, Richard Sandiford wrote:
>> This patch adds internal functions for simple FLT_FN built-in functions,
>> in cases where an associated optab already exists.  Unlike some of the
>> built-in functions, these internal functions never set errno.
>>
>> LDEXP is an odd-one out in that its second operand is an integer.
>> All the others operate on uniform types.
>>
>> The patch also adds a function to query the internal function associated
>> with a built-in function (if any), and another to test whether a given
>> gcall could be replaced by a call to an internal function on the current
>> target (as long as the caller deals with errno appropriately).
>>
>> Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.
>> OK to install?
>>
>> Thanks,
>> Richard
>>
>>
>> gcc/
>> 	* builtins.h (associated_internal_fn): Declare.
>> 	(replacement_internal_fn): Likewise.
>> 	* builtins.c: Include internal-fn.h
>> 	(associated_internal_fn, replacement_internal_fn): New functions.
>> 	* internal-fn.def (DEF_INTERNAL_FLT_FN): New macro.
>> 	(ACOS, ASIN, ATAN, COS, EXP, EXP10, EXP2, EXPM1, LOG, LOG10, LOG1P)
>> 	(LOG2, LOGB, SIGNIFICAND, SIN, SQRT, TAN, CEIL, FLOOR, NEARBYINT)
>> 	(RINT, ROUND, TRUNC, ATAN2, COPYSIGN, FMOD, POW, REMAINDER, SCALB)
>> 	(LDEXP): New functions.
>> 	* internal-fn.c: Include recog.h.
>> 	(unary_direct, binary_direct): New macros.
>> 	(expand_direct_optab_fn): New function.
>> 	(expand_unary_optab_fn): New macro.
>> 	(expand_binary_optab_fn): Likewise.
>> 	(direct_unary_optab_supported_p): Likewise.
>> 	(direct_binary_optab_supported_p): Likewise.
>>
>
>
>> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
>> index 72536da..9f9f9cf 100644
>> --- a/gcc/internal-fn.c
>> +++ b/gcc/internal-fn.c
>> @@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.  If not see
>>   #include "dojump.h"
>>   #include "expr.h"
>>   #include "ubsan.h"
>> +#include "recog.h"
> recog.h?  I don't see anything that would require recognition in this 
> patch.  Is there something in a later patch that needs the recog.h header?

It's needed for:

+  create_output_operand (&ops[0], lhs_rtx, insn_data[icode].operand[0].mode);

I did wonder about adding a comment, but I think it's likely to get out
of date.  I wouldn't be surprised if we add more uses of recog.h stuff
in future.

Richard