Re: [PATCH] centralize builtin function type building

[Nathan Froyd <froydnj at codesourcery dot com>]

On Fri, Apr 22, 2011 at 02:58:31PM -0400, Michael Meissner wrote:
> On Thu, Apr 21, 2011 at 11:04:47AM -0400, Nathan Froyd wrote:
> > - centralizes some infrastructure for defining builtin function types
> >   for frontends by providing a common function that
> >   DEF_FUNCTION_TYPE_FOO macros can call; and
> > 
> > - in order to do that well, it also introduces
> >   build{,_varargs}_function_type_array for cases when
> >   build_function_type_list's interface doesn't work so well.
> 
> 1) For the DEF_FUNCTION_* replacements, the lines exceed the normal 79
>    character limits we use as coding guidelines.

Will fix.

> 2) I'm not a fan of having a varargs function with an explicit count.  I tend
>    to prefer a marker element (like NULL_TREE) as the last element.  In this
>    case, since it is being used in macros that do have fixed elements, it isn't
>    a problem.

We have both kinds of varargs usage in-tree; I think the explicit count
version ought to be preferred, as it makes sharing code between the
takes-varargs version and the takes-count-and-pointer (or the takes-VEC
or takes-std::vector) version easier.  (The explicit count version makes
future function overloading with takes-count-and-pointer more difficult,
though, and of course there's __attribute__((sentinel)) support for
varargs-with-marker functions.)

I suppose you could just write the macros to use
build_function_type_list instead, but it seems nice to delegate all the
accesses to someplace else.

> 3) I'm also not a fan of passing the index into the type array, instead of a
>    tree value to the call.  If you pass a tree, then it allows MD builtins to
>    call it before we switch to having the MD and front end builtins share the
>    bultin index.

Yes, I suppose so.

-Nathan