From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 0FBE5398240A for ; Thu, 17 Nov 2022 07:52:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0FBE5398240A 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 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AH7SSRk020104; Thu, 17 Nov 2022 07:52:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=Cdv5D6CdxqXLFI6+BtxOwSzZ4BCxxplW4TmZvtDfa7k=; b=n9G/B/kZvxddcl0dPAjeDhfTVt/UnUdte/7mtGL/RuAquJ+XDCw7i4j3h48U7YMn1Kck MZbYX4FQr7rWhRKaZxN7Jg2I43Vlw3DI0Dv3Ov70kWKiV85I7Cxt0FMAMa8LdiV7WbTb v9VaTiTvHMpZHGcBP6t8gBiu3twwXTI9G5D75tBEjUeT3bAWesY9quYVc2FkptNM0QTI MirATaSt+iVHMTKfvX6o290RyOQuxCulkzilG0heIt95TqCNLKR+Sk7g4xJ76UW7DqNG mMZzvS5HD+HxCakMd8yh32crlSuZJwvJyYV53m7yqijxK48NfiTjuKZDcsRQsQKXM3TE LQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3kwgkp0jx2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Nov 2022 07:52:36 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AH7SmC2020908; Thu, 17 Nov 2022 07:52:35 GMT Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3kwgkp0jwh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Nov 2022 07:52:35 +0000 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2AH7ojpO001864; Thu, 17 Nov 2022 07:52:33 GMT Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by ppma06ams.nl.ibm.com with ESMTP id 3kt2rjf6fe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Nov 2022 07:52:33 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2AH7qUZO57475364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Nov 2022 07:52:30 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3750DA4053; Thu, 17 Nov 2022 07:52:30 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 148CFA4040; Thu, 17 Nov 2022 07:52:28 +0000 (GMT) Received: from [9.200.44.147] (unknown [9.200.44.147]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 17 Nov 2022 07:52:27 +0000 (GMT) Message-ID: Date: Thu, 17 Nov 2022 15:52:26 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH 2/2] rs6000: Refine integer comparison handlings in rs6000_emit_vector_compare Content-Language: en-US To: Segher Boessenkool Cc: GCC Patches , David Edelsohn , Peter Bergner , Michael Meissner References: <247bf71b-e0ab-7cf7-098b-a106a0764301@linux.ibm.com> <20221116185827.GX25951@gate.crashing.org> From: "Kewen.Lin" In-Reply-To: <20221116185827.GX25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: m7sC8T2fN-nJLF-JwKDY0WZYg-nWEk1F X-Proofpoint-GUID: DTSpTxlODXEKklIIi3Z5m7502Wy8JSfX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-17_04,2022-11-16_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 spamscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 suspectscore=0 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211170056 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP 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 Segher, Thanks for the comments! on 2022/11/17 02:58, Segher Boessenkool wrote: > Hi! > > On Wed, Nov 16, 2022 at 02:51:04PM +0800, Kewen.Lin wrote: >> The current handlings in rs6000_emit_vector_compare is a bit >> complicated to me, especially after we emit vector float >> comparison insn with the given code directly. This patch is >> to refine the handlings for vector integer comparison operators, >> it becomes not recursive, and we don't need the helper function >> rs6000_emit_vector_compare_inner any more. > > That sounds nice. > >> /* In vector.md, we support all kinds of vector float point >> comparison operators in a comparison rtl pattern, we can >> just emit the comparison rtx insn directly here. Besides, >> we should have a centralized place to handle the possibility >> - of raising invalid exception. */ >> - if (GET_MODE_CLASS (dmode) == MODE_VECTOR_FLOAT) >> + of raising invalid exception. Also emit directly for vector >> + integer comparison operators EQ/GT/GTU. */ >> + if (GET_MODE_CLASS (dmode) == MODE_VECTOR_FLOAT >> + || rcode == EQ >> + || rcode == GT >> + || rcode == GTU) > > The comment still says it handles FP only. That would be best to keep > imo: add a separate block of code to handle the integer stuff you want > to add. You get the same or better generated code, the compiler is > smart enough. Code is for the user to read, and C is not a portable > assembler language. OK, I'll make two blocks for FP and integer respectively. I struggled a bit updating this hunk with comments for integer comparison consideration, someone could argue that both can share the same handling if updating the condition. > > This whole series needs to be factored better, it does way too many > things, and only marginally related things, at every step. Or I don't > see it anyway :-) OK, I was thinking patch 1/2 is to unify the current vector float comparison handlings, patch 2/2 is to refine the remaining handlings for vector integer comparison. I'm pleased to factor it better, any suggestions on concrete code is highly appreciated. :) btw, I constructed one test case as below, there is no assembly change before and after this patch. #define GT(a, b) (((a) > (b))) #define GE(a, b) (((a) >= (b))) #define LT(a, b) (((a) < (b))) #define LE(a, b) (((a) <= (b))) #define EQ(a, b) (((a) == (b))) #define NE(a, b) (((a) != (b))) #define TEST_VECT(NAME, TYPE) \ __attribute__ ((noipa)) void test_##NAME##_##TYPE (TYPE *x, TYPE *y, \ int *res, int n) \ { \ for (int i = 0; i < n; i++) \ res[i] = NAME (x[i], y[i]); \ } #include "stdint.h" #define TEST(TYPE) \ TEST_VECT (GT, TYPE) \ TEST_VECT (GE, TYPE) \ TEST_VECT (LT, TYPE) \ TEST_VECT (LE, TYPE) \ TEST_VECT (EQ, TYPE) \ TEST_VECT (NE, TYPE) TEST (int64_t) TEST (uint64_t) TEST (int32_t) TEST (uint32_t) TEST (int16_t) TEST (uint16_t) TEST (int8_t) TEST (uint8_t) BR, Kewen