On Thu, 1 Jul 2021, liuhongt via Gcc-patches wrote:
> +/* Optimize for code like (_Float16) __builtin_sqrtf ((float) f16)
> + since it's not handled in frontend. */
If correct, it *should* be handled in front end (well, middle-end). See
what convert.c:convert_to_real_1 does, with a long comment about when it's
safe for sqrt (the comment says it's safe when P1 >= P2*2+2, which is true
for SFmode and HFmode).
The issue (apart from convert_to_real_1 being earlier than this really
ought to be done - something based on match.pd would be better - but you
can ignore that for now) would be the limitation earlier in that code to
the modes of float and double:
/* Disable until we figure out how to decide whether the functions are
present in runtime. */
/* Convert (float)sqrt((double)x) where x is float into sqrtf(x) */
if (optimize
&& (TYPE_MODE (type) == TYPE_MODE (double_type_node)
|| TYPE_MODE (type) == TYPE_MODE (float_type_node)))
In this case, you *don't* have the sqrtf16 function in the runtime library
(adding _Float16 support to glibc would be good, but runs into various
other complications that would need considering, especially questions of
how if at all it can be added on an architecture before the minimum GCC
version for building glibc for that architecture is recent enough to
support _Float16 for that architecture). So effectively what you'd need
is some way of saying "__builtin_sqrtf16 is available", where "available"
for now means "will be expanded inline", i.e. some combination of
!flag_math_errno and instruction set features. That's not really within
the scope of what the libc_has_function hook does, but it could maybe be
extended to take information about the exact function in question, or
another similar hook could be added.
--
Joseph S. Myers
jos...@codesourcery.com
