| Message ID | 20110823172957.GA10896@hungry-tiger.westford.ibm.com |
|---|---|
| State | New |
| Headers | show |
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. :-)
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
On Tue, Aug 23, 2011 at 7:29 PM, Michael Meissner <meissner@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 <meissner@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 <meissner@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 > meissner@linux.vnet.ibm.com fax +1 (978) 399-6899 >
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_<xxx>, 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.
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_<type>" [ (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_<m_mode>" [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.
On Thu, Aug 25, 2011 at 10:35 PM, Michael Meissner <meissner@linux.vnet.ibm.com> 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_<xxx>, 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 and GCC internal builtins. Not sure if I'd use #ifdef like above or simply stick to .def file like attributions in comments like /* TARGET(ALTIVEC) */ extern vector float __builtin_altivec_vaddfp (vector float, vector float) __attribute__ ((...)); /* LANG(C99) */ double cbrt (double, double) __attribute__ ((...)); we also have fancy things like conditionally adding attributes, for example the ATTR_MATHFN_FPROUNDING stuff. Using #ifdefs for this would work, I think there is a special macro defined for -frounding-math. The idea certainly needs some thoughts, and the target builtins probably have less feature requirements than the middle-end builtins.def stuff. The .h file could also serve as a container for builtin documentation. > 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. Richard. > -- > Michael Meissner, IBM > 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA > meissner@linux.vnet.ibm.com fax +1 (978) 399-6899 >
On Fri, Aug 26, 2011 at 10:19:24AM +0200, Richard Guenther wrote: > On Thu, Aug 25, 2011 at 10:35 PM, Michael Meissner > <meissner@linux.vnet.ibm.com> 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"))); static void v4sf_generic_add (float *, float *, float *, size_t); static void *resolve_v4sf_add (void); static void v4sf_power7_add (float *a, float *b, float *c, size_t n) { size_t n2 = n / 4; size_t n3 = n % 4; while (n2-- > 0) { vector float * v_a = (vector float *)a; vector float * v_b = (vector float *)b; vector float * v_c = (vector float *)c; *v_a = __builtin_vsx_xvaddsp (*v_b, *v_c); a += 4; b += 4; c += 4; } while (n3-- > 0) *a++ = *b++ + *c++; } static void v4sf_altivec_add (float *a, float *b, float *c, size_t n) { if (((((size_t)a) & 0xf) == 0) && ((((size_t)b) & 0xf) == 0) && ((((size_t)c) & 0xf) == 0)) { size_t n2 = n / 4; n %= 4; while (n2-- > 0) { vector float * v_a = (vector float *)a; vector float * v_b = (vector float *)b; vector float * v_c = (vector float *)c; *v_a = __builtin_altivec_vaddfp (*v_b, *v_c); a += 4; b += 4; c += 4; } } } static void v4sf_generic_add (float *a, float *b, float *c, size_t n) { while (n-- > 0) *a++ = *b++ + *c++; } static void * resolve_v4sf_add (void) { if (running_on_power7 ()) return (void *)v4sf_power7_add; else if (running_on_altivec ()) return (void *)v4sf_altivec_add; else return (void *)v4sf_generic_add; } Now, in this particular case, the compiler's auto vectorization might be used, but it is meant to be an example. > > 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. Yep. > > 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_<xxx>, 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 and GCC internal builtins. > > Not sure if I'd use #ifdef like above or simply stick to .def file like > attributions in comments like > > /* TARGET(ALTIVEC) */ > extern vector float __builtin_altivec_vaddfp (vector float, vector > float) __attribute__ ((...)); > > /* LANG(C99) */ > double cbrt (double, double) __attribute__ ((...)); This also works. > we also have fancy things like conditionally adding attributes, for example > the ATTR_MATHFN_FPROUNDING stuff. Using #ifdefs for this would > work, I think there is a special macro defined for -frounding-math. > > The idea certainly needs some thoughts, and the target builtins probably > have less feature requirements than the middle-end builtins.def stuff. > > The .h file could also serve as a container for builtin documentation. > > > 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.
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 <class T> 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.
On Sat, Aug 27, 2011 at 12:12 AM, Mike Stump <mikestump@comcast.net> 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 <class T> > 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.
Index: gcc/doc/configfiles.texi =================================================================== --- gcc/doc/configfiles.texi (revision 177990) +++ gcc/doc/configfiles.texi (working copy) @@ -60,5 +60,17 @@ machine. @item @file{tm_p.h}, which includes the header @file{@var{machine}-protos.h} that contains prototypes for functions in the target @file{.c} file. -FIXME: why is such a separate header necessary? +The @file{tm_p.h} is needed because the @file{@var{machine}-protos.h} +will often times include declarations that include RTL and TREE +datatypes. These references must be bracketed with @code{#ifdef +RTX_CODE} and @code{#ifdef TREE_CODE} respecitively. These +declarations can't go in the normal @file{@var{machine}.h} file +because that file is included before @file{rtl.h} and/or @file{tree.h} +are included. The @file{tm_p.h} is included after @file{rtl.h} or +@file{tree.h} are included. +@item +@file{tm-bu-funcs.def}, includes the machine dependent builtin +functions that use the @code{DEF_BUILTIN_MD} macro to reserve the +machine dependent builtins in the master builtin enum list after the +standard enumerations. @end itemize Index: gcc/tree.h =================================================================== --- gcc/tree.h (revision 177990) +++ gcc/tree.h (working copy) @@ -3503,7 +3503,7 @@ struct GTY(()) tree_function_decl { DECL_FUNCTION_CODE. Otherwise unused. ??? The bitfield needs to be able to hold all target function codes as well. */ - ENUM_BITFIELD(built_in_function) function_code : 11; + ENUM_BITFIELD(built_in_function) function_code : 12; ENUM_BITFIELD(built_in_class) built_in_class : 2; unsigned static_ctor_flag : 1; @@ -3526,7 +3526,7 @@ struct GTY(()) tree_function_decl { unsigned looping_const_or_pure_flag : 1; unsigned has_debug_args_flag : 1; - /* 2 bits left */ + /* 1 bit left */ }; /* The source language of the translation-unit. */ Index: gcc/configure =================================================================== --- gcc/configure (revision 177990) +++ gcc/configure (working copy) @@ -608,6 +608,7 @@ PPLINC PPLLIBS GMPINC GMPLIBS +tm_builtin_funcs target_cpu_default fortran_target_objs cxx_target_objs @@ -17913,7 +17914,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 17916 "configure" +#line 17917 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -18019,7 +18020,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18022 "configure" +#line 18023 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -26796,6 +26797,7 @@ fi + # Echo link setup. if test x${build} = x${host} ; then if test x${host} = x${target} ; then Index: gcc/builtins.def =================================================================== --- gcc/builtins.def (revision 177990) +++ gcc/builtins.def (working copy) @@ -134,6 +134,13 @@ along with GCC; see the file COPYING3. DEF_BUILTIN (ENUM, NAME, BUILT_IN_NORMAL, 0, 0, false, false, \ false, 0, false, false) +/* Allocate the enum and the name for a machine dependent builtin, but do not + actually define it here at all. */ +#undef DEF_BUILTIN_MD +#define DEF_BUILTIN_MD(ENUM, NAME) \ + DEF_BUILTIN (ENUM, NAME, BUILT_IN_MD, 0, 0, false, false, \ + false, 0, false, false) + /* Builtin used by the implementation of GNU OpenMP. None of these are actually implemented in the compiler; they're all in libgomp. */ #undef DEF_GOMP_BUILTIN @@ -173,6 +180,10 @@ along with GCC; see the file COPYING3. #undef ATTR_MATHFN_FPROUNDING_STORE #define ATTR_MATHFN_FPROUNDING_STORE ATTR_NOTHROW_LEAF_LIST +/* Avoid problems with fields that are zeroed by making sure index 0 is not a + legitimate builtin. */ +DEF_BUILTIN_STUB (BUILT_IN_NONE, (const char *)0) + /* Category: math builtins. */ DEF_LIB_BUILTIN (BUILT_IN_ACOS, "acos", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO) DEF_C99_C90RES_BUILTIN (BUILT_IN_ACOSF, "acosf", BT_FN_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO) @@ -789,3 +800,6 @@ DEF_BUILTIN_STUB (BUILT_IN_EH_COPY_VALUE /* OpenMP builtins. */ #include "omp-builtins.def" + +/* Target machine builtins. */ +#include "tm-bu-funcs.def" Index: gcc/configure.ac =================================================================== --- gcc/configure.ac (revision 177990) +++ gcc/configure.ac (working copy) @@ -4923,6 +4923,7 @@ AC_SUBST(c_target_objs) AC_SUBST(cxx_target_objs) AC_SUBST(fortran_target_objs) AC_SUBST(target_cpu_default) +AC_SUBST(tm_builtin_funcs) AC_SUBST_FILE(language_hooks) Index: gcc/lto/Make-lang.in =================================================================== --- gcc/lto/Make-lang.in (revision 177990) +++ gcc/lto/Make-lang.in (working copy) @@ -79,7 +79,8 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIB lto/lto-lang.o: lto/lto-lang.c $(CONFIG_H) coretypes.h debug.h \ flags.h $(GGC_H) langhooks.h $(LANGHOOKS_DEF_H) $(SYSTEM_H) \ $(TARGET_H) $(LTO_H) $(GIMPLE_H) gtype-lto.h gt-lto-lto-lang.h \ - $(EXPR_H) $(LTO_STREAMER_H) + $(EXPR_H) $(LTO_STREAMER_H) builtin-attrs.def builtin-types.def \ + $(BUILTINS_DEF) lto/lto.o: lto/lto.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(OPTS_H) \ toplev.h $(TREE_H) $(TREE_FLOW_H) $(DIAGNOSTIC_CORE_H) $(TM_H) \ $(CGRAPH_H) $(GGC_H) tree-ssa-operands.h $(TREE_PASS_H) \ Index: gcc/config.gcc =================================================================== --- gcc/config.gcc (revision 177990) +++ gcc/config.gcc (working copy) @@ -186,7 +186,10 @@ # configure_default_options # Set to an initializer for configure_default_options # in configargs.h, based on --with-cpu et cetera. - +# +# tm_builtin_funcs Set to additional files in the target directory to +# provide target specific builtin functions. +# # The following variables are used in each case-construct to build up the # outgoing variables: # @@ -238,6 +241,7 @@ default_gnu_indirect_function=no target_gtfiles= need_64bit_hwint= need_64bit_isa= +tm_builtin_funcs= # Don't carry these over build->host->target. Please. xm_file= Index: gcc/Makefile.in =================================================================== --- gcc/Makefile.in (revision 177990) +++ gcc/Makefile.in (working copy) @@ -909,7 +909,9 @@ RTL_H = $(RTL_BASE_H) genrtl.h vecir.h RTL_ERROR_H = $(RTL_H) $(DIAGNOSTIC_CORE_H) READ_MD_H = $(OBSTACK_H) $(HASHTAB_H) read-md.h PARAMS_H = params.h params.def -BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def +BUILTIN_FUNCS_MD = @tm_builtin_funcs@ +BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def \ + tm-bu-funcs.def $(BUILTIN_FUNCS_MD) INTERNAL_FN_DEF = internal-fn.def INTERNAL_FN_H = internal-fn.h $(INTERNAL_FN_DEF) TREE_H = tree.h all-tree.def tree.def c-family/c-common.def \ @@ -1979,6 +1981,19 @@ $(T)crtbeginT.o: crtstuff.c $(GCC_PASSES $(GCC_FOR_TARGET) $(CRTSTUFF_CFLAGS) $(CRTSTUFF_T_CFLAGS) \ -c $(srcdir)/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O \ -o $(T)crtbeginT$(objext) + +# Build the builtin include files that includes the standard builtin file along +# with any machine dependent versions of those files. Note, this files is +# expected to be included multiple times, so don't use mkconfig.sh which adds +# header guards +tm-bu-funcs.def: s-bu-funcs; @true +s-bu-funcs: Makefile + for inc in $(BUILTIN_FUNCS_MD); do \ + echo "#include \"$$inc\""; \ + done > tmp-bu-funcs.def + $(SHELL) $(srcdir)/../move-if-change tmp-bu-funcs.def tm-bu-funcs.def + $(STAMP) s-bu-funcs + # # Compiling object files from source files. @@ -4511,6 +4526,8 @@ mostlyclean: lang.mostlyclean -rm -f gtype.state # Delete genchecksum outputs -rm -f *-checksum.c +# Delete builtin types, attributes, function include files + -rm -f tm-bu-funcs.def # Delete all files made by compilation # that don't exist in the distribution.