Re: [PATCH] centralize builtin function type building
On Thu, Apr 21, 2011 at 05:36:42PM +0200, Richard Guenther wrote:
On Thu, Apr 21, 2011 at 5:04 PM, Nathan Froyd froy...@codesourcery.com
wrote:
This patch does two things:
- 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.
It would have been easier to move all of the builtin-types stuff into
the middle-end, but Fortran doesn't use builtin-types.def. Even if it
did, I suppose it's possible that some new front-end could have its own
set of builtin types, so I'm leaving things as they are.
But this is what should be done, at least for all builtins in the
BUILT_IN_NORMAL category. ISTR Fortran was once running into
the issue of assigning different DECL_FUNCTION_CODE numbers to
those builtins than other languages, breaking LTO.
So, it would be indeed nice to have a central middle-end place to
instantiate those builtins and their required types. I'm not sure how
far we are from that and am too lazy to look right now ...
I agree that it would be better to have a central middle-end place for
this; I'm not entirely sure why Fortran opts to use a separate set of
types; AFAICS, it's a strict subset. Fortran folks...?
The question of decls is something different and unrelated to this
patch, IMHO. Is the patch OK as-is, or should I work on merging the
types into the middle-end in addition?
-Nathan
Re: [PATCH] centralize builtin function type building
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
[PATCH] centralize builtin function type building
This patch does two things:
- 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.
build_function_type_list could have been used instead, but it would lose
the error_mark_node handling provided in the C/C++/Ada/LTO frontends.
This new interface will be necessary for eliminating other uses of
build_function_type anyway.
It would have been easier to move all of the builtin-types stuff into
the middle-end, but Fortran doesn't use builtin-types.def. Even if it
did, I suppose it's possible that some new front-end could have its own
set of builtin types, so I'm leaving things as they are.
The new functions can eliminate some of the games that were played with
the recent backend changes to use build_function_type_list; if this
patch is approved, I'll make the (currently uncommitted) patches that
could use build_function_type_array do so.
Bootstrap and testing in progress on x86_64-unknown-linux-gnu. OK to
commit if successful?
-Nathan
gcc/ada/
* gcc-interface/utils.c (def_fn_type): Delete.
(DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change to use
define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0, DEF_FUNCTION_TYPE_VAR_1):
(DEF_FUNCTION_TYPE_VAR_2, DEF_FUNCTION_TYPE_VAR_3):
(DEF_FUNCTION_TYPE_VAR_4, DEF_FUNCTION_TYPE_VAR_5): Likewise.
gcc/c-family/:
* c-common.c (def_fn_type): Delete.
(DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change to use
define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0, DEF_FUNCTION_TYPE_VAR_1):
(DEF_FUNCTION_TYPE_VAR_2, DEF_FUNCTION_TYPE_VAR_3):
(DEF_FUNCTION_TYPE_VAR_4, DEF_FUNCTION_TYPE_VAR_5): Likewise.
gcc/
* tree.h (build_function_type_array): Declare.
(build_varargs_function_type_array, define_builtin_function_type):
Declare.
* tree.c (build_function_type_array_1): Define.
(build_function_type_array, build_varargs_function_type_array): Define.
(define_builtin_function_type): Define.
gcc/fortran/
* f95-lang.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change
to use define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0): Likewise.
gcc/lto/
* lto-lang.c (def_fn_type): Delete.
(DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change to use
define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0, DEF_FUNCTION_TYPE_VAR_1):
(DEF_FUNCTION_TYPE_VAR_2, DEF_FUNCTION_TYPE_VAR_3):
(DEF_FUNCTION_TYPE_VAR_4, DEF_FUNCTION_TYPE_VAR_5): Likewise.
diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index 1031ee9..6eb136d 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -4952,47 +4952,6 @@ typedef enum c_builtin_type builtin_type;
/* A temporary array used in communication with def_fn_type. */
static GTY(()) tree builtin_types[(int) BT_LAST + 1];
-/* A helper function for install_builtin_types. Build function type
- for DEF with return type RET and N arguments. If VAR is true, then the
- function should be variadic after those N arguments.
-
- Takes special care not to ICE if any of the types involved are
- error_mark_node, which indicates that said type is not in fact available
- (see builtin_type_for_size). In which case the function type as a whole
- should be error_mark_node. */
-
-static void
-def_fn_type (builtin_type def, builtin_type ret, bool var, int n, ...)
-{
- tree args = NULL, t;
- va_list list;
- int i;
-
- va_start (list, n);
- for (i = 0; i n; ++i)
-{
- builtin_type a = (builtin_type) va_arg (list, int);
- t = builtin_types[a];
- if (t == error_mark_node)
- goto egress;
- args = tree_cons (NULL_TREE, t, args);
-}
- va_end (list);
-
- args = nreverse (args);
- if (!var)
-args = chainon (args, void_list_node);
-
- t = builtin_types[ret];
- if (t == error_mark_node)
-goto egress;
- t = build_function_type (t, args);
-
- egress:
- builtin_types[def] = t;
- va_end (list);
-}
-
/* Build the builtin function types and install them in the builtin_types
array for later use in builtin
Re: [PATCH] centralize builtin function type building
On Thu, Apr 21, 2011 at 5:04 PM, Nathan Froyd froy...@codesourcery.com wrote:
This patch does two things:
- 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.
build_function_type_list could have been used instead, but it would lose
the error_mark_node handling provided in the C/C++/Ada/LTO frontends.
This new interface will be necessary for eliminating other uses of
build_function_type anyway.
It would have been easier to move all of the builtin-types stuff into
the middle-end, but Fortran doesn't use builtin-types.def. Even if it
did, I suppose it's possible that some new front-end could have its own
set of builtin types, so I'm leaving things as they are.
But this is what should be done, at least for all builtins in the
BUILT_IN_NORMAL category. ISTR Fortran was once running into
the issue of assigning different DECL_FUNCTION_CODE numbers to
those builtins than other languages, breaking LTO.
So, it would be indeed nice to have a central middle-end place to
instantiate those builtins and their required types. I'm not sure how
far we are from that and am too lazy to look right now ...
Richard.
The new functions can eliminate some of the games that were played with
the recent backend changes to use build_function_type_list; if this
patch is approved, I'll make the (currently uncommitted) patches that
could use build_function_type_array do so.
Bootstrap and testing in progress on x86_64-unknown-linux-gnu. OK to
commit if successful?
-Nathan
gcc/ada/
* gcc-interface/utils.c (def_fn_type): Delete.
(DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change to use
define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0, DEF_FUNCTION_TYPE_VAR_1):
(DEF_FUNCTION_TYPE_VAR_2, DEF_FUNCTION_TYPE_VAR_3):
(DEF_FUNCTION_TYPE_VAR_4, DEF_FUNCTION_TYPE_VAR_5): Likewise.
gcc/c-family/:
* c-common.c (def_fn_type): Delete.
(DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change to use
define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0, DEF_FUNCTION_TYPE_VAR_1):
(DEF_FUNCTION_TYPE_VAR_2, DEF_FUNCTION_TYPE_VAR_3):
(DEF_FUNCTION_TYPE_VAR_4, DEF_FUNCTION_TYPE_VAR_5): Likewise.
gcc/
* tree.h (build_function_type_array): Declare.
(build_varargs_function_type_array, define_builtin_function_type):
Declare.
* tree.c (build_function_type_array_1): Define.
(build_function_type_array, build_varargs_function_type_array): Define.
(define_builtin_function_type): Define.
gcc/fortran/
* f95-lang.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change
to use define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0): Likewise.
gcc/lto/
* lto-lang.c (def_fn_type): Delete.
(DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_1): Change to use
define_builtin_function_type.
(DEF_FUNCTION_TYPE_2, DEF_FUNCTION_TYPE_3, DEF_FUNCTION_TYPE_4):
(DEF_FUNCTION_TYPE_5, DEF_FUNCTION_TYPE_6, DEF_FUNCTION_TYPE_7):
(DEF_FUNCTION_TYPE_VAR_0, DEF_FUNCTION_TYPE_VAR_1):
(DEF_FUNCTION_TYPE_VAR_2, DEF_FUNCTION_TYPE_VAR_3):
(DEF_FUNCTION_TYPE_VAR_4, DEF_FUNCTION_TYPE_VAR_5): Likewise.
diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index 1031ee9..6eb136d 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -4952,47 +4952,6 @@ typedef enum c_builtin_type builtin_type;
/* A temporary array used in communication with def_fn_type. */
static GTY(()) tree builtin_types[(int) BT_LAST + 1];
-/* A helper function for install_builtin_types. Build function type
- for DEF with return type RET and N arguments. If VAR is true, then the
- function should be variadic after those N arguments.
-
- Takes special care not to ICE if any of the types involved are
- error_mark_node, which indicates that said type is not in fact available
- (see builtin_type_for_size). In which case the function type as a whole
- should be error_mark_node. */
-
-static void
-def_fn_type (builtin_type def, builtin_type ret, bool var, int n, ...)
-{
- tree args = NULL, t;
- va_list list;
- int i;
-
- va_start (list, n);
- for (i = 0; i n; ++i)
- {
-
Re: [PATCH] centralize builtin function type building
On Thu, Apr 21, 2011 at 05:36:42PM +0200, Richard Guenther wrote:
On Thu, Apr 21, 2011 at 5:04 PM, Nathan Froyd froy...@codesourcery.com
wrote:
This patch does two things:
- 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.
build_function_type_list could have been used instead, but it would lose
the error_mark_node handling provided in the C/C++/Ada/LTO frontends.
This new interface will be necessary for eliminating other uses of
build_function_type anyway.
It would have been easier to move all of the builtin-types stuff into
the middle-end, but Fortran doesn't use builtin-types.def. Even if it
did, I suppose it's possible that some new front-end could have its own
set of builtin types, so I'm leaving things as they are.
But this is what should be done, at least for all builtins in the
BUILT_IN_NORMAL category. ISTR Fortran was once running into
the issue of assigning different DECL_FUNCTION_CODE numbers to
those builtins than other languages, breaking LTO.
So, it would be indeed nice to have a central middle-end place to
instantiate those builtins and their required types. I'm not sure how
far we are from that and am too lazy to look right now ...
I agree that it is desirable that the backend builtin index not overlap with
the standard builtin index (and front end builtin index). I was starting to
look at this, when I learned Kenneth Zadeck was working on a more comprehensive
solution for backend builtin types. Obviously all 3 of our efforts should be
merged into one goal.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
