Re: [PATCH] Optimize x*x*x*x*x*x using 3 multiplications.

[Roger Sayle <roger at eyesopen dot com>]

On 29 Jul 2003, Gabriel Dos Reis wrote:
> | It might also be worth contacting the glibc/newlib folks to check that
> | they don't already have a name for these functions, even if they don't
> | have any immediate plans to provide implementations.  It would be
> | unfortunate to have this functionality ratified by a future ISO C/C++
> | standard, but under a different name (if its avoidable).
>
> Hmm, I'm not sure I understand the second paragraph.
> Normally, glibc people are not supposed to provide an implementation to
> anything named __builtin_xxx, am I wrong?

By convention, the name "xxx" used in "__builtin_xxx" attempts follow
the naming and parameter passing conventions mandated by the C and C++
standards.  Where possible if the same functionality exists then the
same name should be used.

For example in the C library, the suffix letters "l" and "f", by
convention denote the float and long double forms of a function when used
at the end of an identifier.  This would prefer "powif" over "powfi",
for example.

Normally, this isn't an issue as builtins are either purely GCC_BUILTIN
or LIB_BUILTIN, but this is an example that falls somewhere between the
two.  Another example I'm investigating is "__builtin_memequal" or
"__builtin_memsame" or "__builtin_memeq" which is intended to be a
internal specialization of memcmp/strcmp/strncmp when the result is
only tested for equality/inequality with zero.

I hate naming things and if a higher authority can provide guidance,
I'm more than happy to follow it.  C++'s STL isn't much of a help
here because of the polymorphism.  Perhaps __builtin_Z3powdi?  But I
now understand why you prefer the "f" and "l" before the "i" :>

Roger
--