Thanks for the review. Jeff Law <l...@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
