Fwd: [PATCH 00/29] rs6000: Auto-generate builtins from descriptions [V2]
I apologize for the useless "From" address (and lack of "Reply-To" address) on this patch series. My usual machine is down for maintenance, so I ended up sending this from my laptop, which was clearly not configured well enough for that. My bad. I won't do that again. Meantime, please reply to wschm...@linux.ibm.com for this patch series. Thanks! Bill Forwarded Message ---- Subject: [PATCH 00/29] rs6000: Auto-generate builtins from descriptions [V2] Date: Mon, 27 Jul 2020 09:13:46 -0500 From: Bill Schmidt To: gcc-patches@gcc.gnu.org CC: seg...@kernel.crashing.org, dje@gmail.com, Bill Schmidt From: Bill Schmidt This is a slight reworking of the patches posted on June 17. I have made a couple of improvements, but the general arrangement of the patches is the same as before. Two major things to call out: - I've introduced a uniform set of parsing error codes to make it easier to follow some of the logic when certain conditions occur during parsing. - I reorganized the treatment of built-in stanzas. Before, the stanza conditions were checked prior to initializing entries in the built-in table. Now, all built-ins are initialized, but we check the conditions at expand time to determine whether they should be enabled. This addresses a frequent problem we have with the existing methods, where "#pragma target" doesn't work as expected when changing the target CPU for a single function. As described before, the current built-in support in the rs6000 back end requires at least a master's degree in spelunking to comprehend. It's full of cruft, redundancy, and unused bits of code, and long overdue for a replacement. This is the first part of my project to do that. My intent is to make adding new built-in functions as simple as adding a few lines to a couple of files, and automatically generating as much of the initialization, overload resolution, and expansion logic as possible. This patch series establishes the format of the input files and creates a new program (rs600-gen-builtins) to: * Parse the input files into an internal representation; * Generate a file of #defines (rs6000-vecdefines.h) for eventual inclusion into altivec.h; and * Generate an initialization file to create and initialize tables of built-in functions and overloads. Patches 1, 3-7, and 9-19 contain the logic for rs6000-gen-builtins. Patch 8 provides balanced tree search support for parsing scalability. Patches 2 and 21-27 provide a first cut at the input files. Patch 20 incorporates the new code into the GCC build. Patch 28 adds comments to some existing files that will help during the transition from the previous built-in mechanism. Patch 29 turns on the initialization logic, while leaving GCC's behavior unchanged otherwise. The patch series is constructed so that any prefix set of the patches can be upstreamed without breaking anything. There's still plenty of work left, but I think it will be helpful to get this big chunk of patches upstream to make further progress easier (translation: avoid complex rebases like the one I just went through :-). Following is some additional information about the present and future design that may be of help. The set of patches submitted upstream so far does the relatively straightforward work of reading builtin descriptions from flat files and generating initialization code for builtin and overload tables. It also generates an include file meant to be included in altivec.h, which produces the #defines that map vec_* to __builtin_* functions for external consumption. Data structures are automatically initialized in rs6000_builtins.c: rs6000_autoinit_builtins. Initialized data structures are: - rs6000_gen_builtins: An enumeration of builtin identifiers, such as RS6000_BIF_CPU_SUPPORTS. These names are deliberately different from the existing builtin identifiers so they can co-exist for a while. - rs6000_gen_overloads: An enumeration of overload identifiers, such as RS6000_OVLD_MAX. Again, deliberately different from the old names. Right now I have the two enumerations using nonoverlapping numbers. This is because the two tables were part of one table in the old design, and I haven't yet proven for sure that I can separate them without problems. I think that I can, in which case I will have both enumerations start from zero. - A number of filescope variables representing TREE_TYPEs of functions. These are named _ftype__ ... _ and initialized as tree lists from the prototypes in the input files. The naming scheme for types is described in the code. - rs6000_builtin_info_x: An array indexed by rs6000_gen_builtins containing all the fun stuff for each builtin. The "_x" is because we already have rs6000_builtin_info as the old table, and they need to coexist for a while. - rs6000_overload_info: An array indexed by rs6000_gen_overloads containing all the fun stuff for each overload. - bif_hash: A hash table ma
Re: [PATCH 00/29] rs6000: Auto-generate builtins from descriptions [V2]
Just a reminder this patch series exists and wants a review. :-) Bill On 7/27/20 9:13 AM, Bill Schmidt wrote: From: Bill Schmidt This is a slight reworking of the patches posted on June 17. I have made a couple of improvements, but the general arrangement of the patches is the same as before. Two major things to call out: - I've introduced a uniform set of parsing error codes to make it easier to follow some of the logic when certain conditions occur during parsing. - I reorganized the treatment of built-in stanzas. Before, the stanza conditions were checked prior to initializing entries in the built-in table. Now, all built-ins are initialized, but we check the conditions at expand time to determine whether they should be enabled. This addresses a frequent problem we have with the existing methods, where "#pragma target" doesn't work as expected when changing the target CPU for a single function. As described before, the current built-in support in the rs6000 back end requires at least a master's degree in spelunking to comprehend. It's full of cruft, redundancy, and unused bits of code, and long overdue for a replacement. This is the first part of my project to do that. My intent is to make adding new built-in functions as simple as adding a few lines to a couple of files, and automatically generating as much of the initialization, overload resolution, and expansion logic as possible. This patch series establishes the format of the input files and creates a new program (rs600-gen-builtins) to: * Parse the input files into an internal representation; * Generate a file of #defines (rs6000-vecdefines.h) for eventual inclusion into altivec.h; and * Generate an initialization file to create and initialize tables of built-in functions and overloads. Patches 1, 3-7, and 9-19 contain the logic for rs6000-gen-builtins. Patch 8 provides balanced tree search support for parsing scalability. Patches 2 and 21-27 provide a first cut at the input files. Patch 20 incorporates the new code into the GCC build. Patch 28 adds comments to some existing files that will help during the transition from the previous built-in mechanism. Patch 29 turns on the initialization logic, while leaving GCC's behavior unchanged otherwise. The patch series is constructed so that any prefix set of the patches can be upstreamed without breaking anything. There's still plenty of work left, but I think it will be helpful to get this big chunk of patches upstream to make further progress easier (translation: avoid complex rebases like the one I just went through :-). Following is some additional information about the present and future design that may be of help. The set of patches submitted upstream so far does the relatively straightforward work of reading builtin descriptions from flat files and generating initialization code for builtin and overload tables. It also generates an include file meant to be included in altivec.h, which produces the #defines that map vec_* to __builtin_* functions for external consumption. Data structures are automatically initialized in rs6000_builtins.c: rs6000_autoinit_builtins. Initialized data structures are: - rs6000_gen_builtins: An enumeration of builtin identifiers, such as RS6000_BIF_CPU_SUPPORTS. These names are deliberately different from the existing builtin identifiers so they can co-exist for a while. - rs6000_gen_overloads: An enumeration of overload identifiers, such as RS6000_OVLD_MAX. Again, deliberately different from the old names. Right now I have the two enumerations using nonoverlapping numbers. This is because the two tables were part of one table in the old design, and I haven't yet proven for sure that I can separate them without problems. I think that I can, in which case I will have both enumerations start from zero. - A number of filescope variables representing TREE_TYPEs of functions. These are named _ftype__ ... _ and initialized as tree lists from the prototypes in the input files. The naming scheme for types is described in the code. - rs6000_builtin_info_x: An array indexed by rs6000_gen_builtins containing all the fun stuff for each builtin. The "_x" is because we already have rs6000_builtin_info as the old table, and they need to coexist for a while. - rs6000_overload_info: An array indexed by rs6000_gen_overloads containing all the fun stuff for each overload. - bif_hash: A hash table mapping builtin function names to pointers to their rs6000_builtin_info_x entries. - ovld_hash: A hash table mapping overload names to pointers to their rs6000_overload_info entries. The new initialization code is called from rs6000_init_builtins. Currently this function continues to do its existing initialization work, but also initializes the new tables (and then ignores them). The old initialization code contains a lot of ad hoc hackery to handle different kinds of functions that
[PATCH 00/29] rs6000: Auto-generate builtins from descriptions [V2]
From: Bill Schmidt This is a slight reworking of the patches posted on June 17. I have made a couple of improvements, but the general arrangement of the patches is the same as before. Two major things to call out: - I've introduced a uniform set of parsing error codes to make it easier to follow some of the logic when certain conditions occur during parsing. - I reorganized the treatment of built-in stanzas. Before, the stanza conditions were checked prior to initializing entries in the built-in table. Now, all built-ins are initialized, but we check the conditions at expand time to determine whether they should be enabled. This addresses a frequent problem we have with the existing methods, where "#pragma target" doesn't work as expected when changing the target CPU for a single function. As described before, the current built-in support in the rs6000 back end requires at least a master's degree in spelunking to comprehend. It's full of cruft, redundancy, and unused bits of code, and long overdue for a replacement. This is the first part of my project to do that. My intent is to make adding new built-in functions as simple as adding a few lines to a couple of files, and automatically generating as much of the initialization, overload resolution, and expansion logic as possible. This patch series establishes the format of the input files and creates a new program (rs600-gen-builtins) to: * Parse the input files into an internal representation; * Generate a file of #defines (rs6000-vecdefines.h) for eventual inclusion into altivec.h; and * Generate an initialization file to create and initialize tables of built-in functions and overloads. Patches 1, 3-7, and 9-19 contain the logic for rs6000-gen-builtins. Patch 8 provides balanced tree search support for parsing scalability. Patches 2 and 21-27 provide a first cut at the input files. Patch 20 incorporates the new code into the GCC build. Patch 28 adds comments to some existing files that will help during the transition from the previous built-in mechanism. Patch 29 turns on the initialization logic, while leaving GCC's behavior unchanged otherwise. The patch series is constructed so that any prefix set of the patches can be upstreamed without breaking anything. There's still plenty of work left, but I think it will be helpful to get this big chunk of patches upstream to make further progress easier (translation: avoid complex rebases like the one I just went through :-). Following is some additional information about the present and future design that may be of help. The set of patches submitted upstream so far does the relatively straightforward work of reading builtin descriptions from flat files and generating initialization code for builtin and overload tables. It also generates an include file meant to be included in altivec.h, which produces the #defines that map vec_* to __builtin_* functions for external consumption. Data structures are automatically initialized in rs6000_builtins.c: rs6000_autoinit_builtins. Initialized data structures are: - rs6000_gen_builtins: An enumeration of builtin identifiers, such as RS6000_BIF_CPU_SUPPORTS. These names are deliberately different from the existing builtin identifiers so they can co-exist for a while. - rs6000_gen_overloads: An enumeration of overload identifiers, such as RS6000_OVLD_MAX. Again, deliberately different from the old names. Right now I have the two enumerations using nonoverlapping numbers. This is because the two tables were part of one table in the old design, and I haven't yet proven for sure that I can separate them without problems. I think that I can, in which case I will have both enumerations start from zero. - A number of filescope variables representing TREE_TYPEs of functions. These are named _ftype__ ... _ and initialized as tree lists from the prototypes in the input files. The naming scheme for types is described in the code. - rs6000_builtin_info_x: An array indexed by rs6000_gen_builtins containing all the fun stuff for each builtin. The "_x" is because we already have rs6000_builtin_info as the old table, and they need to coexist for a while. - rs6000_overload_info: An array indexed by rs6000_gen_overloads containing all the fun stuff for each overload. - bif_hash: A hash table mapping builtin function names to pointers to their rs6000_builtin_info_x entries. - ovld_hash: A hash table mapping overload names to pointers to their rs6000_overload_info entries. The new initialization code is called from rs6000_init_builtins. Currently this function continues to do its existing initialization work, but also initializes the new tables (and then ignores them). The old initialization code contains a lot of ad hoc hackery to handle different kinds of functions that require extra behavior. The new design removes as much of that as possible, and instead uses syntax in the flat file to generate flags and
