From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 5F07C38930E6 for ; Thu, 18 Jun 2020 22:48:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F07C38930E6 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05IMWjqQ138157; Thu, 18 Jun 2020 18:48:45 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 31rekd46ac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 18:48:45 -0400 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 05IMWicg138059; Thu, 18 Jun 2020 18:48:44 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 31rekd469y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 18:48:44 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 05IMdVrR021333; Thu, 18 Jun 2020 22:48:43 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma01wdc.us.ibm.com with ESMTP id 31q6bdf65y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 22:48:43 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 05IMmguk49414402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Jun 2020 22:48:42 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6E52D124053; Thu, 18 Jun 2020 22:48:42 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AC9F5124052; Thu, 18 Jun 2020 22:48:41 +0000 (GMT) Received: from lexx (unknown [9.160.10.60]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 18 Jun 2020 22:48:41 +0000 (GMT) Message-ID: <04285b294f00dfdca1d95357c06368761b982e73.camel@vnet.ibm.com> Subject: Re: [PATCH 00/28] rs6000: Auto-generate builtins from descriptions From: will schmidt To: wschmidt@linux.ibm.com, gcc-patches@gcc.gnu.org Cc: segher@kernel.crashing.org, dje.gcc@gmail.com, willschm@linux.ibm.com Date: Thu, 18 Jun 2020 17:48:41 -0500 In-Reply-To: References: <8d5673e3e1ae2d887469162ad99efdf8dd5010cf.camel@vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_21:2020-06-18, 2020-06-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 cotscore=-2147483648 mlxlogscore=999 impostorscore=0 bulkscore=0 spamscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180168 X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 22:48:47 -0000 On Thu, 2020-06-18 at 17:01 -0500, Bill Schmidt wrote: > Thanks for the review, Will! Responses below... > > On 6/18/20 11:08 AM, will schmidt wrote: > > On Wed, 2020-06-17 at 14:46 -0500, Bill Schmidt wrote: > > > I posted a version of these patches back in stage 4 (February), > > > but we agreed that holding off until stage 1 was a better idea. > > > Since then I've made more progress and reorganized the patches > > > accordingly. This group of patches lays groundwork, but does not > > > actually change GCC's behavior yet, other than to generate the > > > new initialization information and ignore it. > > > > > > 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 (rs6000-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 builtin mechanism. > > > > > > The patch series is constructed so that any prefix set of the > > > patches > > > can be upstreamed without breaking anything, so we can take the > > > reviews slowly. 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. > > > > > > Thanks in advance for your reviews! > > > > > > > I've read through the series. Nothing significant, just a few > > cosmetic > > nits, i've called them out below here, versus replying to the > > individual emails. > > > > generally lgtm. > > thanks > > -Will > > > > > > > Bill Schmidt (28): > > > rs6000: Initial create of rs6000-gen-builtins.c > > > > ok > > > rs6000: Add initial input files > > > > Whitespace/tabs in "Legal values of " blurb. > > otherwise ok > > Urk. Will fix. > > > rs6000: Add file support and functions for diagnostic support > > > > ok > > > rs6000: Add helper functions for parsing > > > > ok > > > rs6000: Add functions for matching types, part 1 of 3 > > > > ok > > > > > rs6000: Add functions for matching types, part 2 of 3 > > > > ok > > > > > rs6000: Add functions for matching types, part 3 of 3 > > > > ok > > > > > rs6000: Red-black tree implementation for balanced tree search > > > > ok > > > > > rs6000: Main function with stubs for parsing and output > > > > ok > > > > > rs6000: Parsing built-in input file, part 1 of 3 > > > > ok > > > rs6000: Parsing built-in input file, part 2 of 3 > > > > ok > > > rs6000: Parsing built-in input file, part 3 of 3 > > > > ok > > > rs6000: Parsing of overload input file > > > > use enums or consts instead of hardcoding values ? > > Is this specifically about MAXOVLDSTANZAS, MAXOVLDS, or something > else? > If the former, I guess I can define these in const decls instead of > using #define if that's preferred. No issue with those. I was noting the constants used as the return values in the parse_ovld_entry() function. You have them clearly documented there. +/* Parse one two-line entry in the overload file. Return 0 for EOF, 1 for + success, 2 for end-of-stanza, and 6 for a parsing failure. */ So just a suggestion to use other defined values for that. I didn't notice those numbers used in the other patches, so maybe this is already fixed up elsewhere. Thanks -Will