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 04DE63858D20 for ; Thu, 30 May 2024 03:14:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04DE63858D20 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 04DE63858D20 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=1717038864; cv=none; b=joeM8Y9NMhxv44CHii0cyLOe+BhRWjKupPirKLHidq2ddrBtHvph5wX0eCpJjCLy6H9nh4nDRwLdxzH7udSjadGTSP8CU87DkH6a4gUmT4FpqhZrGhDyhIHlLUufBYIuPRMS/SKl48b+XKPkP92FwjjFcXbE5ecj8UcCsD9o2VM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717038864; c=relaxed/simple; bh=vyMac/0BLXXtMLdzw5K+wYeySEN/1SFWyFzSg4IzmvY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=SGViQM15RCIhyIFYyX3fbK4zklCEdOQOF+OCOOrmX+kDycWcPZ8zaIiZ6s0RTqOWtX9XRR9JZy6g+XeJMO9MggQZMPkB93zAxSThJAxu3KytGq/ftq9WAQnIzHEsKEUy9gL9J8EwdnNjGOsHzIYcIEW8Varf7aKrvZH85ASEVKc= ARC-Authentication-Results: i=1; server2.sourceware.org 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 44U37rgR013452; Thu, 30 May 2024 03:14:22 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=fTj30IacDs5o04iF7zfqmjNT/Fmiuull6PXJJdEngRw=; b=Ja3NzwTdHrbySnvfsMPIYKyVks1MjO7VD+EEiCTz7xPsasPkAcFbhBh2S7ZamnyWntFd bpY876dwL6o1ThCj7RoQw+Q/blcLzqhTBVGoP/vkxdgSUAdR1ojRH9bYP0qhIW7VcxHh r8KGuuteoStCvxxJbabTAg+ax/5I4CqMrFg5SjW9l1UZXMQtQNfAvSx7bPGVXkEz54Uz gbbEw28XDgn0TUcYpwIJlMJL76bZov8CobF99whvZs53K0cE1PLZtdqIPgvs2+NdsWAG qecWLZ3tS6Ateijn47lirkNH84xUo0dMkBjotdQWc0cNlkcwiBaZpuc8qKAyGONhHyFv WQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3yeh9100gs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 May 2024 03:14:21 +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 44U3EL9Y023052; Thu, 30 May 2024 03:14:21 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 3yeh9100gj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 May 2024 03:14:21 +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 44U0ji6e029537; Thu, 30 May 2024 03:14:18 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3ydpayqkbj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 May 2024 03:14:18 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 44U3EDa252035900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 May 2024 03:14:15 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 186BB2004D; Thu, 30 May 2024 03:14:13 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93CC720065; Thu, 30 May 2024 03:14:11 +0000 (GMT) Received: from [9.200.103.244] (unknown [9.200.103.244]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 30 May 2024 03:14:11 +0000 (GMT) Message-ID: <5d188c8a-7f98-4cb3-abc5-752613282a5c@linux.ibm.com> Date: Thu, 30 May 2024 11:14:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH-1, rs6000] Add a new type of CC mode - CCBCD for bcd insns [PR100736, PR114732] To: "Kewen.Lin" 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> Content-Language: en-US From: HAO CHEN GUI In-Reply-To: <53003cc6-a67c-0faf-5b4d-824de5bddb88@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: k6Yg7wj5-iu5siSYmZW0xCaZuFIUe7m0 X-Proofpoint-ORIG-GUID: nt-y4VvfTYqBl26UosVCJO8hLMfvXebO 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-29_16,2024-05-28_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 bulkscore=0 clxscore=1015 adultscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2405300023 X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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 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. Actually rs6000 already use "lt" code to test if bit 0 is set for vector compare instructions. The following expand is an example. (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. Looking forward to your and Segher's further invaluable comments. Thanks Gui Haochen