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 22D1E3848039 for ; Fri, 21 May 2021 12:53:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 22D1E3848039 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14LCYKjQ135124; Fri, 21 May 2021 08:53:18 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 38pcb69npj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 08:53:18 -0400 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 14LCaUFi148279; Fri, 21 May 2021 08:53:17 -0400 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 38pcb69np0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 08:53:17 -0400 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 14LClFbE007956; Fri, 21 May 2021 12:53:16 GMT Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by ppma02wdc.us.ibm.com with ESMTP id 38jyu2r7tx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 May 2021 12:53:16 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 14LCrFBU40960346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 21 May 2021 12:53:15 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D8C8AAE063; Fri, 21 May 2021 12:53:15 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 767BFAE05F; Fri, 21 May 2021 12:53:15 +0000 (GMT) Received: from Bills-MacBook-Pro.local (unknown [9.163.5.209]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 21 May 2021 12:53:15 +0000 (GMT) Reply-To: wschmidt@linux.ibm.com Subject: Re: [PATCH 00/57] Replace the Power target-specific built-in machinery To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com References: <20210520215742.GU10366@gate.crashing.org> From: Bill Schmidt Message-ID: <388f72f5-2ea5-cf24-facc-1fa83f8ec508@linux.ibm.com> Date: Fri, 21 May 2021 07:53:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <20210520215742.GU10366@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-TM-AS-GCONF: 00 X-Proofpoint-GUID: piThdnbjAV6Cb0w-_ZWslfCuolKwb3k- X-Proofpoint-ORIG-GUID: dujNKcMEziwFQqfiWGfOZLVdPPBoYHZb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-21_04:2021-05-20, 2021-05-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 lowpriorityscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 priorityscore=1501 clxscore=1015 mlxscore=0 malwarescore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105210074 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Fri, 21 May 2021 12:53:21 -0000 On 5/20/21 4:57 PM, Segher Boessenkool wrote: > Is there some (semi-)automatic way to compare the results of the old > and new systems? Yes...very "semi".  There's a patch in the series that updates the information printed from -mdebug=builtin.  I use this to print the builtins generated by the old and new versions, and run them through a Python script to look for anything missing or added, any mismatches in the type system, mismatches in const/pure/etc., that sort of thing.  I found quite a lot of mistakes this way and got them fixed ahead of time.  In the script I maintain a table of expected differences, where there were just errors before, etc., and there's a short doc string with each of them.  So I can go back and look at that if we run into any discrepancies in the future.  The script doesn't have long-term value beyond that; once we delete the old version in a future patch, it won't have anything to compare against. >> Patch 0057: Fix one last late-breaking change >> >> Keeping the code up-to-date with upstream has been fun. When I >> rebased to create the patch set, I found one new issue where a >> small change had been made to the overload handling for the >> vec_insert builtins. This patch reflects that change into the >> new handling. My version of git is having trouble with >> interactive rebasing, so it was easier to just add the extra patch. > What breaks by keeping this fix after the other patches? Nothing truly breaks.  There is a VSX-efficient implementation of vec_insert and a less-efficient implementation.  Late in GCC 11, somebody recognized the VSX-efficient implementation could be used in more situations.  Without this patch, we still use the less-efficient implementation in the new version. > >> (3) A number of built-ins used "long" for DImode types, which would >> break these for 32-bit. I changed those arguments and return values >> to "long long" to avoid such problems, when those built-ins were not >> restricted to 64-bit mode already. There aren't many such cases. > You can do this for 64-bit-only builtins as well -- the actual argument > type is never visible (to the user), and everything becomes modes early. > Yep -- in fact, the old system generally used a (V2)DImode type for such things, and I've just translated all of those to (vector) long long in the new prototypes. Thanks for the ongoing review! Bill