On Nov 6, 2005, at 6:03 AM, Paolo Carlini wrote:
So - can't you work with some preprocessor magic and a define, if
the builtins are available?
I don't really understand this last remark of yours: is it an
alternate solution?!? Any preprocessor magic has to rely on a new
preprocessor builtin, in case, because there is no consistent,
unequivocal way to know whether the builtins are available for the
actual target, we already explored that some time ago, in our
(SUSE) gcc-development list too.
Coincidentally I also explored this option in another product. We
ended up implementing it and it seemed to work quite well. It did
require the back end to "register" with the preprocessor those
builtins it implemented, and quite frankly I don't know exactly how
that registration worked. But from a library writer's point of view,
it was pretty cool. For example:
inline
unsigned
count_bits32(_CSTD::uint32_t x)
{
#if __has_intrinsic(__builtin_count_bits32)
return __builtin_count_bits32(x);
#else
x -= (x >> 1) & 0x55555555;
x = (x & 0x33333333) + ((x >> 2) & 0x33333333);
x = (x + (x >> 4)) & 0x0F0F0F0F;
x += x >> 8;
x += x >> 16;
return (unsigned)x & 0xFF;
#endif
}
In general, if __builtin_XYZ is implemented in the BE, then
__has_intrinsic(__builtin_XYZ) answers true, else it answers false.
This offers a lot of generality to the library writer. Generic
implementations are written once and for all (in the library), and
need not be inlined. Furthermore, the library can test
__has_intrinsic(__builtin_XYZ) in places relatively unrelated to
__builtin_XYZ (such as a client of __builtin_XYZ) and perform
different algorithms in the client depending on whether the builtin
existed or not (clients of the atomic builtins might especially value
such flexibility).
Also during testing the "macro-ness" of this facility can come in
really handy:
// Test generic library "builtins"
#undef __has_intrinsic
#define __has_intrinsic(x) 0
// All __builtins are effectively disabled here,
// except of course those not protected by __has_intrinsic.
The work in the back end seems somewhat eased as well as the back end
can completely ignore the builtin unless it wants to implement it.
And then there is only the extra "registration" with __has_intrinsic
to deal with.
My apologies for rehashing an old argument. If there are pointers to:
we already explored that some time ago, in our (SUSE) gcc-
development list too.
I would certainly take the time to review that thread.
-Howard
