Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Sat, Aug 27, 2011 at 12:12 AM, Mike Stump wrote: > On Aug 26, 2011, at 7:19 AM, Michael Meissner wrote: The alternative is something like what Kenney and Mike are doing in their private port, where they have new syntax in the MD file for builtins. >>> >>> But are those user-exposed builtins? Certainly interesting to combine >>> builtin definition and the instruction it expands to. >> >> Yes, these are user exposed builtins. Massive amounts of user exposed >> builtins >> (Mike said he needs 13 bits for the builtin index). I think it would be >> better >> if Mike comments on this. > > I gave the quick intro yesterday. You wind up specifying the built-ins that > you have, and the generator does things like assign enum values, create a > file that appears the builtins into the user name space from the __builtin_ > namespace, generate compilation test cases for all the built-ins with all > different types they support. Generate executable testcases to ensure > everything works flawlessly. We have mods to the overload builtin mechanism > so that one can do things like: > > template > T foo(T x, T y) { > x = add(x, y); > return x; > } > > Or, if you perfer the C version: > > int fooi(int x, int y) { > return add(x, y); > } > > short foos(short x, short y) { > return add(x, y); > } > > and have it work out just fine when T is instantiated with all the various > types that are supported by the hardware, and it works in C. This permits a > nice api for the machine builtins, as you don't have to mangle in types into > the builtin-name. The system is complete enough to handle the needs of > anything coming down the pike in the next decade. It can handle input/output > parameters that have register assignments. It can handle reference > parameters (like the input/output parameters, but these are done as values in > memory. The generator builds up _all_ the types one needs, handles all the > registration and all the wiring up for codegen. There is a mechanism to > remap arguments going to the rtl generators, so the operand ordering of the > builtin doesn't have to match the operand ordering of the md pattern for the > semantics that back the builtin. There is a beefy macro system built into > the generator so that you can have nice simple patterns and it is beefier > than the iterators one can use today. So, for example, we have: > > (define_special_iterator imath3 [add sub mul]) > > to define some built-ins that are regular with respect to the operation, but, > this isn't a code nor mode iterator, it just iterators the pattern with the > string substituted. For machines with any regularity, the patterns wind up > being smaller and easier to maintain. I'd be happy to answer questions about > it. Maybe you can even post the code somewhere? Richard.
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Aug 26, 2011, at 7:19 AM, Michael Meissner wrote: >>> The alternative is something like what Kenney and Mike are doing in their >>> private port, where they have new syntax in the MD file for builtins. >> >> But are those user-exposed builtins? Certainly interesting to combine >> builtin definition and the instruction it expands to. > > Yes, these are user exposed builtins. Massive amounts of user exposed > builtins > (Mike said he needs 13 bits for the builtin index). I think it would be > better > if Mike comments on this. I gave the quick intro yesterday. You wind up specifying the built-ins that you have, and the generator does things like assign enum values, create a file that appears the builtins into the user name space from the __builtin_ namespace, generate compilation test cases for all the built-ins with all different types they support. Generate executable testcases to ensure everything works flawlessly. We have mods to the overload builtin mechanism so that one can do things like: template T foo(T x, T y) { x = add(x, y); return x; } Or, if you perfer the C version: int fooi(int x, int y) { return add(x, y); } short foos(short x, short y) { return add(x, y); } and have it work out just fine when T is instantiated with all the various types that are supported by the hardware, and it works in C. This permits a nice api for the machine builtins, as you don't have to mangle in types into the builtin-name. The system is complete enough to handle the needs of anything coming down the pike in the next decade. It can handle input/output parameters that have register assignments. It can handle reference parameters (like the input/output parameters, but these are done as values in memory. The generator builds up _all_ the types one needs, handles all the registration and all the wiring up for codegen. There is a mechanism to remap arguments going to the rtl generators, so the operand ordering of the builtin doesn't have to match the operand ordering of the md pattern for the semantics that back the builtin. There is a beefy macro system built into the generator so that you can have nice simple patterns and it is beefier than the iterators one can use today. So, for example, we have: (define_special_iterator imath3 [add sub mul]) to define some built-ins that are regular with respect to the operation, but, this isn't a code nor mode iterator, it just iterators the pattern with the string substituted. For machines with any regularity, the patterns wind up being smaller and easier to maintain. I'd be happy to answer questions about it.
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Fri, Aug 26, 2011 at 10:19:24AM +0200, Richard Guenther wrote: > On Thu, Aug 25, 2011 at 10:35 PM, Michael Meissner > wrote: > > On Wed, Aug 24, 2011 at 11:06:55AM +0200, Richard Guenther wrote: > >> This basically would make DECL_BUILT_IN_CLASS no longer necessary > >> if all targets where converted, right? (We don't currently have any > >> BUILT_IN_FRONTEND builtins). That would sound appealing if this > >> patch weren't a partial transition ;) > > > > Or we could reduce it to 1 bit if we aren't going to change all of the > > backends. > > > >> Now for the possible downsides. How can we reliably distinguish > >> middle-end from target builtins for purpose of lazy initialization? > >> Doesn't this complicate the idea of "pluggable" targets, thus > >> something like a hybrid ppc / spu compiler? In this light merging > >> middle-end and target builtin enums and arrays sounds like a step > >> backward. > > > > If we are willing to pay the storage costs, we could have 1 or 2 bytes for > > builtin owner, and 2 bytes for builtin index, and then reserve 0 for > > standard > > builtins and 1 for machine dependent builtins. However, then you still have > > the potential problem that sooner or later somebody else will omit the > > checks. > > I don't think that the issue you only can index BUILT_IN_NORMAL builtins > in built_in_decls is an issue and worth thinking about at all. It's simply > bugs. I've probably spent about 2-3 weeks total tracking down those bugs in the past, because they are hard to pin down, but if we don't want to merge the two numbers it isn't a deal breaker to me. It was more while I'm playing in the builtin space, fix the problem. > > We could reserve a fixed range for plugin builtins if you think that is > > desirable. > > Oh, plugin builtins - I didn't even think about the possibility of having > those ;) > > In the end I think we should stick with BUILT_IN_CLASS and maybe > add BUILT_IN_PLUGIN then ;) I think if we do this, we should re-use the front end builtin class, and add methods that front ends can add their builtins to the main list. Otherwise we need to grow the class by 1 bit. > >> What I _do_ like is having common machinery for defining builtins. > >> Though instead of continuing the .def file way with all the current > >> warts of ways of adding attributes, etc. to builtins I would have > >> prefered a genbuiltins.c program that can parse standard C > >> declarations and generate whatever is necessary to setup the > >> builtin decls. Thus, instead of > >> > >> DEF_GCC_BUILTIN (BUILT_IN_CLZ, "clz", BT_FN_INT_UINT, > >> ATTR_CONST_NOTHROW_LEAF_LIST) > >> > >> have simply > >> > >> int __builtin_clz (unsigned int) __attribute__((const,nothrow,leaf)); > >> > >> in a header file which genbuiltins.c would parse. My first idea > >> when discussing this was a -fgenbuiltins flag to the C frontend > >> (because that already can do all the parsing ...), but Micha suggested > >> a parser that can deal with the above is easy enough to "re-implement". > > > > Yes, that is certainly do-able. My main intention is to see what kind of > > infrastructure people wanted before changing all of the ppc builtins. > > Sure. I agree that all the duplicated code we have in backends for a > way to create target builtins, defining enums (or not) for them and > having a way to reference them for targetm.builtin_decl (or not) is bad. > But unifying those, or providing common infrastructure for them should > be orthogonal to the issue whether we want to "merge" the builtin > classes or their storage in some way (I think we don't). It would of > course be nice if the infrastructure to create taget builtins were > generic enough to eventually handle builtin creation in the middle-end > (and the frontends) as well. > > >> Hm, I guess this pushes back a bit on your patch. Sorry for that. > >> If you're not excited to try the above idea, can you split out the > >> pieces that do the .def file thing for rs6000, keeping the separation > >> of md and middle-end builtin arrays and enums? > > > > I have several goals for the 4.7 time frame: > > > > 1) Make target attribute and pragma enable appropriate machine dependent > > builtins; > > That's now something completely new ;) Why do we need builtins for this? I ran out of time when I added target pragma support in 4.6 to enable the builtins for target functions. We don't need new builtins, but the ppc backend needs to enable the builtins that exist when the target is selected, which the x86 already does. In the end, I want to be able to do: void v4sf_add (float *, float *, float *, size_t) __attribute__ ((__ifunc__ ("resolve_v4sf_add"))); static void v4sf_power7_add (float *, float *, float *, size_t) __attribute__ ((__target__ ("cpu=power7"))); static void v4sf_altivec_add (float *, float *, float *, size_t) __attribute__ ((__target__ ("altivec")));
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Thu, Aug 25, 2011 at 10:35 PM, Michael Meissner wrote: > On Wed, Aug 24, 2011 at 11:06:55AM +0200, Richard Guenther wrote: >> This basically would make DECL_BUILT_IN_CLASS no longer necessary >> if all targets where converted, right? (We don't currently have any >> BUILT_IN_FRONTEND builtins). That would sound appealing if this >> patch weren't a partial transition ;) > > Or we could reduce it to 1 bit if we aren't going to change all of the > backends. > >> Now for the possible downsides. How can we reliably distinguish >> middle-end from target builtins for purpose of lazy initialization? >> Doesn't this complicate the idea of "pluggable" targets, thus >> something like a hybrid ppc / spu compiler? In this light merging >> middle-end and target builtin enums and arrays sounds like a step >> backward. > > If we are willing to pay the storage costs, we could have 1 or 2 bytes for > builtin owner, and 2 bytes for builtin index, and then reserve 0 for standard > builtins and 1 for machine dependent builtins. However, then you still have > the potential problem that sooner or later somebody else will omit the checks. I don't think that the issue you only can index BUILT_IN_NORMAL builtins in built_in_decls is an issue and worth thinking about at all. It's simply bugs. > We could reserve a fixed range for plugin builtins if you think that is > desirable. Oh, plugin builtins - I didn't even think about the possibility of having those ;) In the end I think we should stick with BUILT_IN_CLASS and maybe add BUILT_IN_PLUGIN then ;) >> What I _do_ like is having common machinery for defining builtins. >> Though instead of continuing the .def file way with all the current >> warts of ways of adding attributes, etc. to builtins I would have >> prefered a genbuiltins.c program that can parse standard C >> declarations and generate whatever is necessary to setup the >> builtin decls. Thus, instead of >> >> DEF_GCC_BUILTIN (BUILT_IN_CLZ, "clz", BT_FN_INT_UINT, >> ATTR_CONST_NOTHROW_LEAF_LIST) >> >> have simply >> >> int __builtin_clz (unsigned int) __attribute__((const,nothrow,leaf)); >> >> in a header file which genbuiltins.c would parse. My first idea >> when discussing this was a -fgenbuiltins flag to the C frontend >> (because that already can do all the parsing ...), but Micha suggested >> a parser that can deal with the above is easy enough to "re-implement". > > Yes, that is certainly do-able. My main intention is to see what kind of > infrastructure people wanted before changing all of the ppc builtins. Sure. I agree that all the duplicated code we have in backends for a way to create target builtins, defining enums (or not) for them and having a way to reference them for targetm.builtin_decl (or not) is bad. But unifying those, or providing common infrastructure for them should be orthogonal to the issue whether we want to "merge" the builtin classes or their storage in some way (I think we don't). It would of course be nice if the infrastructure to create taget builtins were generic enough to eventually handle builtin creation in the middle-end (and the frontends) as well. >> Hm, I guess this pushes back a bit on your patch. Sorry for that. >> If you're not excited to try the above idea, can you split out the >> pieces that do the .def file thing for rs6000, keeping the separation >> of md and middle-end builtin arrays and enums? > > I have several goals for the 4.7 time frame: > > 1) Make target attribute and pragma enable appropriate machine dependent > builtins; That's now something completely new ;) Why do we need builtins for this? > 2) Make it less likely we will again be bitten by code that blindly > references built_in_decl without checking if it is MD or standard; I don't think this is important at all. Proposed solution: transition builtin decl access to a functional interface: tree built_in_decl (enum built_in_code) which when building with C++ will get you warnings if indexed with a bougs enum type or an integer type. > 3) Make at least the MD builtins created on demand. It would be nice to do > the standard builtins as well, but that may somewhat more problematical. > I do think all references to built_in_decl and implicit_built_in_decl > should be moved to a macro wrapper. To a (inline) function wrapper with the same name, indeed. > If we restrict the types and attributes for a C like header file, it shouldn't > be that hard (famous last words). I would think adding #ifdef also, so: > > #ifdef __ALTIVEC__ > extern vector float __builtin_altivec_vaddfp (vector float, vector > float) __attribute__ ((...)); > #endif > > The backend would need to specify a list of valid #ifdef's and the mapping to > TARGET_, and valid extra types with a mapping to the internal type node. Yes. For the middle-end/frontend stuff we also need a way to specify the difference between C89 and C99 builtins an
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Aug 25, 2011, at 1:35 PM, Michael Meissner wrote: > The alternative is something like what Kenney and Mike are doing in their > private port, where they have new syntax in the MD file for builtins. I think the issue is actually largely orthogonal. In our code, we generate which code is used by a description for the built-in, picking a simple one: (define_builtin "port_add" "port_add_" [ (define_outputs [(var_operand:T_ALL_DI 0)]) (define_inputs [(var_operand:T_ALL_DI 1) (var_operand:T_ALL_DI 2) (var_operand:T_ALL_DI 3)]) (define_rtl_pattern "port_add_" [0 1 2 3]) (attributes [pure]) ] ) from this, we generate everything needed. Way under the hood, there is a set of enum values, but, you wouldn't ever see them. There isn't a one-to-one correspondence as we permit overloading. We start as 0 and increase, but, we could just as easily start at LAST_MI_BUILTIN+1. Things like T_ALL_DI as iterators which describe the front-end type to use and how it relates to modes in rtl-land. T_DI might be long, and T_UDI might be unsigned long, the mode for both is DImode.
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Wed, Aug 24, 2011 at 11:06:55AM +0200, Richard Guenther wrote: > This basically would make DECL_BUILT_IN_CLASS no longer necessary > if all targets where converted, right? (We don't currently have any > BUILT_IN_FRONTEND builtins). That would sound appealing if this > patch weren't a partial transition ;) Or we could reduce it to 1 bit if we aren't going to change all of the backends. > Now for the possible downsides. How can we reliably distinguish > middle-end from target builtins for purpose of lazy initialization? > Doesn't this complicate the idea of "pluggable" targets, thus > something like a hybrid ppc / spu compiler? In this light merging > middle-end and target builtin enums and arrays sounds like a step > backward. If we are willing to pay the storage costs, we could have 1 or 2 bytes for builtin owner, and 2 bytes for builtin index, and then reserve 0 for standard builtins and 1 for machine dependent builtins. However, then you still have the potential problem that sooner or later somebody else will omit the checks. We could reserve a fixed range for plugin builtins if you think that is desirable. > What I _do_ like is having common machinery for defining builtins. > Though instead of continuing the .def file way with all the current > warts of ways of adding attributes, etc. to builtins I would have > prefered a genbuiltins.c program that can parse standard C > declarations and generate whatever is necessary to setup the > builtin decls. Thus, instead of > > DEF_GCC_BUILTIN(BUILT_IN_CLZ, "clz", BT_FN_INT_UINT, > ATTR_CONST_NOTHROW_LEAF_LIST) > > have simply > > int __builtin_clz (unsigned int) __attribute__((const,nothrow,leaf)); > > in a header file which genbuiltins.c would parse. My first idea > when discussing this was a -fgenbuiltins flag to the C frontend > (because that already can do all the parsing ...), but Micha suggested > a parser that can deal with the above is easy enough to "re-implement". Yes, that is certainly do-able. My main intention is to see what kind of infrastructure people wanted before changing all of the ppc builtins. > Hm, I guess this pushes back a bit on your patch. Sorry for that. > If you're not excited to try the above idea, can you split out the > pieces that do the .def file thing for rs6000, keeping the separation > of md and middle-end builtin arrays and enums? I have several goals for the 4.7 time frame: 1) Make target attribute and pragma enable appropriate machine dependent builtins; 2) Make it less likely we will again be bitten by code that blindly references built_in_decl without checking if it is MD or standard; 3) Make at least the MD builtins created on demand. It would be nice to do the standard builtins as well, but that may somewhat more problematical. I do think all references to built_in_decl and implicit_built_in_decl should be moved to a macro wrapper. If we restrict the types and attributes for a C like header file, it shouldn't be that hard (famous last words). I would think adding #ifdef also, so: #ifdef __ALTIVEC__ extern vector float __builtin_altivec_vaddfp (vector float, vector float) __attribute__ ((...)); #endif The backend would need to specify a list of valid #ifdef's and the mapping to TARGET_, and valid extra types with a mapping to the internal type node. The alternative is something like what Kenney and Mike are doing in their private port, where they have new syntax in the MD file for builtins. -- 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
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Tue, Aug 23, 2011 at 7:29 PM, Michael Meissner wrote: > Over the years, it has been a problem for ports like the PowerPC that have > more builtins than the standard list. Code that references the built_in_decls > and implicit_built_in_decls arrays are supposed to check DECL_BUILT_IN_CLASS > being BUILT_IN_NORMAL first, but every so often code doesn't do this check, > and > it checks random pieces of memory, because the backend builtin function number > is greater than the number of machine independent builtins. > > This patch is an infrastructure patch that lets backends decide to merge their > builtin enumerations at the end of the standard set of enumerations. Only the > PowerPC port is modified with this patch. If this goes in, the port > maintainers for the other ports with a lot of builtins (x86, spu, etc.) can > decide whether to move to this new infrastructure. > > This patch growes the bit field that has the builtin function number by one > bit. Strictly speaking for the PowerPC, we don't need it just yet, but it > gives us a margin of safety. Right now, there are about 730 machine > independent builtins and 950 PowerPC builtins, which gives us a margin of 350 > more builtins before the field is full, if I didn't grow the size of the > builtin function bitfield. > > When I was documenting the tm-bu-funcs.def file built by the Makefile, I > noticed there was a FIXME comment asking why tm_p.h existed, so I added an > explanation. > > Originally I wanted to allow the MD file to allow all of the builtins to be > initialized when the main builtins are setup. This would have fit into the > infrastructure, by having MD versions of builtin-attrs.def and > builtin-types.def. However, the problem is Fortran doesn't use the C, C++, > and > LTO common builtin infrastructure, but it does want to initialize the target > builtins via the targetm.init_builtins hook. So I decided not to include that > support in this patch. > > These are meant to be committed as a single patch, but I have separated the > patches into a machine indendepent patch, and one that moves the PowerPC to > use > this new infrastructure. > > I anticipate there will be additional patches in the powerpc builtin area to > allow target attributes and pragmas to enable new builtins, but that will be > in > a later patch. I wanted in this patch to have a fairly minimimal set of > changes. > > I have bootstrapped and done make checks on the PowerPC with no regressions. > In addition, I have bootstrapped the x86_64 to make sure it continues to work > for a port that wasn't modified. Are these patches ok to commit? This basically would make DECL_BUILT_IN_CLASS no longer necessary if all targets where converted, right? (We don't currently have any BUILT_IN_FRONTEND builtins). That would sound appealing if this patch weren't a partial transition ;) Now for the possible downsides. How can we reliably distinguish middle-end from target builtins for purpose of lazy initialization? Doesn't this complicate the idea of "pluggable" targets, thus something like a hybrid ppc / spu compiler? In this light merging middle-end and target builtin enums and arrays sounds like a step backward. What I _do_ like is having common machinery for defining builtins. Though instead of continuing the .def file way with all the current warts of ways of adding attributes, etc. to builtins I would have prefered a genbuiltins.c program that can parse standard C declarations and generate whatever is necessary to setup the builtin decls. Thus, instead of DEF_GCC_BUILTIN(BUILT_IN_CLZ, "clz", BT_FN_INT_UINT, ATTR_CONST_NOTHROW_LEAF_LIST) have simply int __builtin_clz (unsigned int) __attribute__((const,nothrow,leaf)); in a header file which genbuiltins.c would parse. My first idea when discussing this was a -fgenbuiltins flag to the C frontend (because that already can do all the parsing ...), but Micha suggested a parser that can deal with the above is easy enough to "re-implement". Hm, I guess this pushes back a bit on your patch. Sorry for that. If you're not excited to try the above idea, can you split out the pieces that do the .def file thing for rs6000, keeping the separation of md and middle-end builtin arrays and enums? Thanks, Richard. > [gcc] > 2011-08-23 Michael Meissner > > * doc/configfiles.texi (tm_p.h): Document why tm_p.h is needed. > (tm-bu-funcs.def): Document the include file that includes the > machine dependent builtin functions. > > * tree.h (struct tree_function_decl): Grow function code field by > 1 bit to allow for machines with lots of builtins. > > * builtins.def (BUILT_IN_NONE): Reserve builtin index 0 so it is > not a legitimate builtin. > (DEF_BUILTIN_MD): New macro for defining machine dependent > builtins. > (toplevel): Include tm-bu-funcs.def. > > * configure.ac (tm_builtin_funcs): New autoconf variable to merge > backend b
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On 08/23/2011 07:29 PM, Michael Meissner wrote: + tm_builtin_funcs="$(tm_builtin_funcs) config/rs6000/rs6000-builtin.def" + tm_builtin_funcs="$(tm_builtin_funcs) config/rs6000/rs6000-builtin.def" These should use braces; build parts are otherwise okay. Paolo
Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins
On Aug 23, 2011, at 10:29 AM, Michael Meissner wrote: > This patch growes the bit field that has the builtin function number by one > bit. I _use_ 13 bits on my port. If you do 13, we won't have to change it for 10 years, I promise. :-)
[PATCH] Add infrastructure to merge standard builtin enums with backend builtins
Over the years, it has been a problem for ports like the PowerPC that have more builtins than the standard list. Code that references the built_in_decls and implicit_built_in_decls arrays are supposed to check DECL_BUILT_IN_CLASS being BUILT_IN_NORMAL first, but every so often code doesn't do this check, and it checks random pieces of memory, because the backend builtin function number is greater than the number of machine independent builtins. This patch is an infrastructure patch that lets backends decide to merge their builtin enumerations at the end of the standard set of enumerations. Only the PowerPC port is modified with this patch. If this goes in, the port maintainers for the other ports with a lot of builtins (x86, spu, etc.) can decide whether to move to this new infrastructure. This patch growes the bit field that has the builtin function number by one bit. Strictly speaking for the PowerPC, we don't need it just yet, but it gives us a margin of safety. Right now, there are about 730 machine independent builtins and 950 PowerPC builtins, which gives us a margin of 350 more builtins before the field is full, if I didn't grow the size of the builtin function bitfield. When I was documenting the tm-bu-funcs.def file built by the Makefile, I noticed there was a FIXME comment asking why tm_p.h existed, so I added an explanation. Originally I wanted to allow the MD file to allow all of the builtins to be initialized when the main builtins are setup. This would have fit into the infrastructure, by having MD versions of builtin-attrs.def and builtin-types.def. However, the problem is Fortran doesn't use the C, C++, and LTO common builtin infrastructure, but it does want to initialize the target builtins via the targetm.init_builtins hook. So I decided not to include that support in this patch. These are meant to be committed as a single patch, but I have separated the patches into a machine indendepent patch, and one that moves the PowerPC to use this new infrastructure. I anticipate there will be additional patches in the powerpc builtin area to allow target attributes and pragmas to enable new builtins, but that will be in a later patch. I wanted in this patch to have a fairly minimimal set of changes. I have bootstrapped and done make checks on the PowerPC with no regressions. In addition, I have bootstrapped the x86_64 to make sure it continues to work for a port that wasn't modified. Are these patches ok to commit? [gcc] 2011-08-23 Michael Meissner * doc/configfiles.texi (tm_p.h): Document why tm_p.h is needed. (tm-bu-funcs.def): Document the include file that includes the machine dependent builtin functions. * tree.h (struct tree_function_decl): Grow function code field by 1 bit to allow for machines with lots of builtins. * builtins.def (BUILT_IN_NONE): Reserve builtin index 0 so it is not a legitimate builtin. (DEF_BUILTIN_MD): New macro for defining machine dependent builtins. (toplevel): Include tm-bu-funcs.def. * configure.ac (tm_builtin_funcs): New autoconf variable to merge backend builtins into the main builtin handling. Include rs6000-builtin.def on rs6000. * configure: Regenerate. * config.gcc (rs6000*, powerpc*): Ditto. * Makefile.in (BUILTINS_DEF): Add support for merging machine dependent builtins at the end of the standard builtins. (BUILTIN_FUNCS_MD): Ditto. (c-family/c-common.o): Ditto. (mostlyclean): Ditto. (tm-bu-funcs.def): New header built that includes machine dependent builtins. * config/rs6000/rs6000-protos.h (rs6000_builtin_types): Move here from rs6000.h. Adjust for merging the rs6000 builtins after the standard builtins. (rs6000_builtin_decls): Ditto. * config/rs6000/rs6000-builtin.def (toplevel): Add support for being included in builtins.def to define all rs6000 builtins after the standard builtins. Delete RS6000_BUILTIN_EQUATE. (RS6000_BUILTIN_FIRST): New macros to mark start and end of various classes of builtins. Replace existing overload start and end markers. (ALTIVEC_BUILTIN_FIRST): Ditto. (ALTIVEC_BUILTIN_OVERLOADED_FIRST): Ditto. (ALTIVEC_BUILTIN_OVERLOADED_LAST): Ditto. (ALTIVEC_BUILTIN_LAST): Ditto. (SPE_BUILTIN_FIRST): Ditto. (SPE_BUILTIN_LAST): Ditto. (PAIRED_BUILTIN_FIRST): Ditto. (PAIRED_BUILTIN_LAST): Ditto. (VSX_BUILTIN_FIRST): Ditto. (VSX_BUILTIN_OVERLOADED_FIRST): Ditto. (VSX_BUILTIN_OVERLOADED_LAST): Ditto. (VSX_BUILTIN_LAST): Ditto. (RS6000_BUILTIN_LAST): Ditto. (VECTOR_BUILTIN_*): Move so the builtins are in the Altivec range. * config/rs6000/rs6000-c.c (struct altivec_builtin_types): Adjust for merging the rs6000 builtins after th