On Tue, Aug 23, 2011 at 7:29 PM, Michael Meissner <meiss...@linux.vnet.ibm.com> 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 <meiss...@linux.vnet.ibm.com> > > * 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 the standard builtins. > (altivec_overloaded_builtins): Ditto. > > * config/rs6000/rs6000.c (rs6000_builtin_decls): Adjust for merging > the rs6000 builtins after the standard builtins. > (struct builtin_description): Ditto. > (builtin_classify): Ditto. > (builtin_function_type): Ditto. > (rs6000_builtin_decl): Ditto. > (enable_mask_for_builtins): Ditto. > (rs6000_builtin_vectorized_function): Ditto. > (struct builtin_description_predicates): Ditto. > (def_builtin): If function is already defined, ignore rather than > causing an error. > (altivec_expand_builtin): Use OVERLOADED_BUILTIN_P. > (altivec_init_builtin): Ditto. > (rs6000_init_builtin_types): Split initializing types from the > rest of the builtin support. Add initial steps to making > rs6000_init_builtins be called more than one. Drop testing for > VSX for building basic types, just like occurs for Altivec, SPE, > etc. > (rs6000_init_builtins): Ditto. > (rs6000_common_init_builtins): Ditto. > > * config/rs6000/rs6000.h (enum rs6000_builtins): Delete, merge > rs6000 builtins to the end of the standard builtins. > (rs6000_builtin_types): Move to rs6000-protos.h. > (rs6000_builtin_decls): Ditto. > (ALTIVEC_BUILTIN_P): New macros mapping builtin function index to > machine type. > (ALTIVEC_BUILTIN_OVERLOADED_P): Ditto. > (VSX_BUILTIN_P): Ditto. > (VSX_BUILTIN_OVERLOADED_P): Ditto. > (OVERLOADED_BUILTIN_P): Ditto. > (SPEC_BUILTIN_P): Ditto. > (PAIRED_BUILTIN_P): Ditto. > (MISC_BUILTIN_P): Ditto. > > [gcc/lto] > 2011-08-19 Michael Meissner <meiss...@linux.vnet.ibm.com> > > * Make-lang.in (lto/lto-lang.o): Adjust dependencies for merging > backend builtins into main 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 >
