__builtin_generic

__builtin_generic

[Kean Johnston]

Hello all,

I have recently updated may OpenServer header files and
library functions, and it has exposed a problem (for me,
but bear with me, this can be very useful). The native
compiler supports a construct called "__builtin_generic"
that works like this.

It looks like a normal function call, whose prototype
would be somevalue __builtin_generic (..., const char *).
"somevalue" changes; read on. The last argument is 
format specifier that indicates argument types and
function names. When this is encountered, if any of
the arguments before the string are of one of the
types in the string, then the function rferenced is
called as a replacement to the __builtin_generic call.
I doubt I explained this propperly so consider this
example:

__builtin_generic (x, "ld:cosld;f:cosf;:cos");

If 'x' is of type long double ("ld"), then cosld()
will be called. If it is of type float ("f") then
cosf() will be called. Otherwise, for any other
type, simple cos() will be called. You can see the
value in this, especially for defining macros that
can take any argument type, and have them call the
correct function. In fact, that's exactly what
our math.h does, for many functions where there are
different library calls based on the argument type.

I started trying to implement this in 2.95.3 (yes
I know its old, its what I have to work with) and
I am afraid I simply don't have the compiler
internals smarts to do it. Specifically, how to
change the function call from __builtin_generic
to the one chosen. I am sure given enough time I
could figure it out but if anyone with any real
smarts finds this interesting and can see as much
use for it as I do (no that's not a self-serving
statement) then I'd love to work with you to
implement this. I can work in the 3.3 tree if I
must - I'll backport it to 2.95.3 myself.

Anyone care to lend a hand? Comments? Questions?

Kean.

Re: __builtin_generic

[Falk Hueffner]

"Kean Johnston" <jkj@sco.com> writes:

> I doubt I explained this propperly so consider this
> example:
> 
> __builtin_generic (x, "ld:cosld;f:cosf;:cos");
> 
> If 'x' is of type long double ("ld"), then cosld() will be
> called. If it is of type float ("f") then cosf() will be
> called. Otherwise, for any other type, simple cos() will be called.

Thhis should be doable with __builtin_types_compatible_p, which
already exists in recent gccs.

-- 
	Falk

RE: __builtin_generic

[Kean Johnston]

> Thhis should be doable with __builtin_types_compatible_p, which
> already exists in recent gccs.
Sort of, in an indirect, implement-it-yourself way. The whole
idea of __builtin_generic is that it really replaces the actual
function call based on the type. So if I call cos((long double)x),
it will actually emit a call to cosld(). This handles, at the
*COMPILER* level, the equivalent of that macro the manual lists.

So yes, I agree that types_compat is at least part of the
solution, __builtin_generic is considerably cleaner (in my opinion).
The types_compatibile mechanism relies on the fact that the
optimizer will recognize a constant condition and hopefully
(I do mean hopefully, its not like the optimizer doesn't have
bugs, or like its even always active) call the desired function.
__builtin_generic is pretty much a guarantee that it will do the
right thing.

Doesn't seem like theres a lot of enthusiasm for this though,
so I guess if I want to see it implemented I'll have to do it
myself. I hope the lack of enthusiasm isnt because of my FQDN,
as has happened on other lists.

Kean

Re: __builtin_generic

[Richard Henderson]

On Sat, Apr 05, 2003 at 01:00:35AM -0800, Kean Johnston wrote:
> Doesn't seem like theres a lot of enthusiasm for this though,
> so I guess if I want to see it implemented I'll have to do it
> myself.

Possibly because we believe that the solution we have now is good
enough, modulo the fact that proper C++ function overloading is
really the only Really Clean solution.


r~