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 7EFC738582AC for ; Fri, 7 Jul 2023 20:18:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EFC738582AC Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 367JvkiG014989; Fri, 7 Jul 2023 20:18:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=saiBQ3TbADb681Im+LckRbjzwhkM435ddUnvmB6sVQk=; b=hQjN6yKIqkRKQSNJ2iuN1wawPqzYwztX1s1LQDohQJlID/D96BmMs3PKC3HUctzslFxq fHG4kKnXVdSJnmhwGLZLSCfs0kBjxkUf+R4fIKH0vTqTMlfbCeVVyBmW0GwTbu9QzoAo AyfMuRXKWsTJuRY8rI0QKWp61Mc/V/LJ8UnJqVybQxzjq67ApyRY3YvWjbNEcP7NEy/1 +YzCdJLD5NqQLJxEfl0KM9pRc7PkKa1BTGES80q91F58Mf6Lqud3XDwe1RWUfV3B51IA GcUX2x1ONIPF4OU//CgWuq9vuVn0C1juCWIGT8Tuj0Vv5mr32uJQPJXsMc8JXCqD7oUv XQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rpsaw8jhx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2023 20:18:56 +0000 Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 367KBIap030202; Fri, 7 Jul 2023 20:18:56 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rpsaw8jhj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2023 20:18:56 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 367IGkdZ029960; Fri, 7 Jul 2023 20:18:55 GMT Received: from smtprelay07.dal12v.mail.ibm.com ([9.208.130.99]) by ppma04dal.us.ibm.com (PPS) with ESMTPS id 3rjbs6g02b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2023 20:18:55 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay07.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 367KIrZs20644174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Jul 2023 20:18:53 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 875B958058; Fri, 7 Jul 2023 20:18:53 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 08EBC58057; Fri, 7 Jul 2023 20:18:53 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.61.18.149]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 7 Jul 2023 20:18:52 +0000 (GMT) Message-ID: <1498f65c3cc7596f6053d37fdb2da21bbfac9cef.camel@us.ibm.com> Subject: Re: [PATCH] rs6000, fix vec_replace_unaligned builtin arguments From: Carl Love To: "Kewen.Lin" , cel@us.ibm.com Cc: Peter Bergner , Segher Boessenkool , gcc-patches@gcc.gnu.org, David Edelsohn Date: Fri, 07 Jul 2023 13:18:52 -0700 In-Reply-To: References: <63afb57c80647d16859c4a2bdd83fa2bbcdc843e.camel@us.ibm.com> <75ba2b38-4865-cd7c-d44a-731a6e5ec707@linux.ibm.com> <2a4d8d366ebe7e4069388dc4f9820f60735d04ce.camel@us.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: tDbwDqQF8nJJnw-45ko5SJi8QgQ8SJCr X-Proofpoint-GUID: PfKHqUz-NqROdvDNvbv8l4Xj0QiJevZz X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-07_14,2023-07-06_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 mlxscore=0 spamscore=0 bulkscore=0 phishscore=0 impostorscore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307070184 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Kewen: On Mon, 2023-06-19 at 11:50 +0800, Kewen.Lin wrote: > > generated the vinsd instruction for the two calls with the first > > argument of unsigned long long int. When the first argument of the > > builtin is changed to the correct type, vector unsigned char the > > builtin generates the vinsw instruction instead. The change occurs > > in > > two places resulting in reducing the counts for vinsd by two and > > increasing the counts for vinsw by two. The other calls to the > > builtin > > are either vector ints or vector floats which generate the vinsw > > instruction. Changing the first argument in those calls to vector > > unsigned char still generate the vinsw instruction. > > But it did expose something odd and needed to be handled in this > change. > I had a further check, for the below test case: > > #include "altivec.h" > > #ifdef ORIG > vector unsigned char foo (vector unsigned long long v){ > unsigned long long val = 678ull; > return vec_replace_unaligned (v, val, 7); > } > #else > vector unsigned char foo (vector unsigned long long v){ > unsigned long long val = 678ull; > return vec_replace_unaligned ((vector unsigned char)v, val, 7); > } > #endif > > Without this patch (-DORIG required to match the previous prototype), > it would generate vinsd; while with this proposed patch, it would > generate vinsw. I think it's unexpected since users can still have > the need to replace a doubleword size of chunk but give a constant > which can be represented by int. The previous way can support it, > while the new way can't. So we should have some way to distinguish > it, we have some special-casing in function > altivec_resolve_overloaded_builtin, could you have a check and try > there? Thanks! I added the needed handling in altivec_resolve_overloaded_builtin to address the issue with the built-in generating the correct instruction for the unsigned long long cases in the test file. I added an additional test file with the above test case. It was put into a new test file as it requires the -flax-vector-conversions argument. I felt that it was best to separate the tests that need/do not need the -flax- vector-conversions argument. Note, adding the additional case statement RS6000_OVLD_VEC_REPLACE_UN to handle the three argument built-in vec_replace_unaligned in altivec_resolve_overloaded_builtin exposed an issue with function find_instance. Function find_instance assumes there are only two arguments in the builtin. There are no checks on the actual number of arguments used by the built-in. This leads to an error in tree_operand_check_failed() when using find_builtin. The find_buitin function was extended to handle 2 or 3 arguments with a check to make sure the number of arguments is either 2 or 3. FYI, I also noticed in the current patch the names in rs6000- builtins.def and rs6000-overload.def for builtin_altivec_vreplace_un still reflect the type of the first argument. The current patch changes the first argument to vuc, but the naming didn't all get updated. I think the names should be changed to reflect the name of the second argument since the first arguments are all identical. For example: -- a/gcc/config/rs6000/rs6000-builtins.def +++ b/gcc/config/rs6000/rs6000-builtins.def @@ -3388,29 +3388,29 @@ const vull __builtin_altivec_vpextd (vull, vull); VPEXTD vpextd {} - const vuc __builtin_altivec_vreplace_un_uv2di (vull, unsigned long long, \ - const int<4>); - VREPLACE_UN_UV2DI vreplace_un_v2di {} + const vuc __builtin_altivec_vreplace_un_udi (vuc, unsigned long long, \ + const int<4>); + VREPLACE_UN_UDI vreplace_un_di {} The name changes will ripple thru files rs6000-builtins.def, rs6000- overload.def and vsx.md. I did all the naming as well in the new version 3 of the patch. Carl