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