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 EE7A9385E45C for ; Fri, 31 May 2024 07:30:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE7A9385E45C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EE7A9385E45C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717140630; cv=none; b=N19M3znL33pW7pT0yOo4e+ZRm4RKZclcKoher2UaglFH89xGa80VYvM/aN+lWZR0mZTHLn8KnaMwuO+3eRscoF0W8r6vrw0hW/Qf+4vNH+dlkflFu80rQ9qt+VNBM7kjfj+9t+8UP2s3yNDRCfGHV6d59vmRyO88myP6Kb9WEF4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717140630; c=relaxed/simple; bh=q/mBCpyHqB5Npq0ZdOaz0nqL+HwcUSygKQVfBjbnA78=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=dhvlFQPcV7Lpt7K7ZwTSIk+VfpKuRQX8kS8x8FTBDnYaSWCJMrV7YMUahYblVyiTI0ofpRh++cLoNDAPgqGHIVRaC1aum2+5xUKEY1aRJsGthxhsxRmtM6Jg6Nyuew8J0uNGfFpnf1Gg2rL0O3oYP9JB6S2Aj/KEUTBClguNq+k= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 44V7IMf2022085; Fri, 31 May 2024 07:30:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc : content-transfer-encoding : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=pp1; bh=UDVwTaUj3zQ1h8n4j3We5NcKy/9C+hj18j7da23YfW0=; b=QDWbc7Ieh/7+BlXqO/b+SDBB5yRDSZ+MlnRxcijMqo0/GKqHIVc/l2u9Bb4qlvRBn+yF RRoPxFgHvAsOIvX0b/UQ8fCrE6LffFvA3x7IB3llnYhkXMSWWv176Skqucyrv7jbhJzU 94xGlbCRTJFR1bbPmNltH9MnrYAItFIM3Zo/9BmYW+pL0YUXxu8m4cb7Ps5ZSJTW9rfC yDzii4cpqYTqVQkVr50dR0/Id5M16UirtwqbwWfWueTtw3kzYcG6JO868K+Bqt/BV0Ex O2mCi49BiRMZcZgYe30ZIJruIpQ7yJZ8jTS20U50J4yKi2Tjr4eNVbRhOmz9WyjA1H4x /Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3yfa16r0xq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 May 2024 07:30:25 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 44V7UPRm012699; Fri, 31 May 2024 07:30:25 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3yfa16r0xh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 May 2024 07:30:25 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 44V5EABT028981; Fri, 31 May 2024 07:30:23 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3ydpayxmeb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 May 2024 07:30:23 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 44V7UHJO34537874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 31 May 2024 07:30:20 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D268020043; Fri, 31 May 2024 07:30:17 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E1E932004B; Fri, 31 May 2024 07:30:15 +0000 (GMT) Received: from [9.197.255.9] (unknown [9.197.255.9]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 31 May 2024 07:30:15 +0000 (GMT) Message-ID: <47305dc6-8977-bd8f-82a9-eb5d70c7b4db@linux.ibm.com> Date: Fri, 31 May 2024 15:30:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732] Content-Language: en-US To: HAO CHEN GUI Cc: Segher Boessenkool , David , Peter Bergner , gcc-patches References: <65719e53-d438-45db-b0cb-2829ba6ac7e2@linux.ibm.com> <53003cc6-a67c-0faf-5b4d-824de5bddb88@linux.ibm.com> <5d188c8a-7f98-4cb3-abc5-752613282a5c@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: <5d188c8a-7f98-4cb3-abc5-752613282a5c@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 8szg4zKQUDpXZS1G_EaORMIwVwUSb86M X-Proofpoint-GUID: 3QI5Ld4YBkITGE6ftE2vgiiD8jbLPPFi X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-05-31_04,2024-05-30_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 priorityscore=1501 impostorscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2405310056 X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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: Hi Haochen, on 2024/5/30 11:14, HAO CHEN GUI wrote: > Hi Kewen, > > 在 2024/5/29 13:26, Kewen.Lin 写道: >> I can understand re-using "unordered" and "eq" will save some efforts than >> doing with unspecs, but they are actually RTL codes instead of bits on the >> specific hardware CR, a downside is that people who isn't aware of this >> design point can have some misunderstanding when reading/checking the code >> or dumping, from this perspective unspecs (with reasonable name) can be >> more meaningful. Normally adopting RTL code is better since they have the >> chance to be considered (optimized) in generic pass/code, but it isn't the >> case here as we just use the code itself but not be with the same semantic >> (meaning). Looking forward to others' opinions on this, if we want to adopt >> "unordered" and "eq" like what this patch does, I think we should at least >> emphasize such points in rs6000-modes.def. > > Thanks so much for your comments. IMHO, the core is if we can re-define > "unordered" or "eq" for certain CC mode on a specific target. If we can't or > it's unsafe, we have to use the unspecs. In this case, I just want to define > the code "unordered" on CCBCD as testing if the bit 3 is set on this CR field. But my point is that "unordered" has its semantic, it looks a bit tricky to adopt it on the result from BCD comparison when which only has "invalid" and "overflow" other than normal ones, though I can understand that this patch wants to use it to test bit 3 since for float comparison bit 3 is for "unordered". However, IMHO it would be more clear to have one unspec to test bit 3 when bit 3 doesn't actually mean unordered result. > Actually rs6000 already use "lt" code to test if bit 0 is set for vector > compare instructions. The following expand is an example. Yeah, but it doesn't mean it's the most sensible way to do this, IMHO it suffers from the similar issue and can be improved as well. > > (define_expand "vector_ae__p" > [(parallel > [(set (reg:CC CR6_REGNO) > (unspec:CC [(ne:CC (match_operand:VI 1 "vlogical_operand") > (match_operand:VI 2 "vlogical_operand"))] > UNSPEC_PREDICATE)) > (set (match_dup 3) > (ne:VI (match_dup 1) > (match_dup 2)))]) > (set (match_operand:SI 0 "register_operand" "=r") > (lt:SI (reg:CC CR6_REGNO) > (const_int 0))) > (set (match_dup 0) > (xor:SI (match_dup 0) > (const_int 1)))] > > I think the "lt" on CC just doesn't mean it compares if CC value is less than an > integer. It just tests the "lt" bit (bit 0) is set or not on this CC. But bit 0 doesn't mean for "lt" comparison result in this context any more. BR, Kewen > > Looking forward to your and Segher's further invaluable comments. > > Thanks > Gui Haochen