From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 32CA03858D33; Mon, 17 Jul 2023 13:45:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 32CA03858D33 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 (m0353722.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36HDgdqH027710; Mon, 17 Jul 2023 13:45:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : mime-version : content-type : content-transfer-encoding; s=pp1; bh=fubccXGR5OMyE0KErcJQItMqNG825ZyXM351YspWd10=; b=IkoqX3YYZt86AWZprluVP8FijGCeq/rUt4FSBJUbKZFsE6c88+Wqle7QLmiV6xMpIQuz hw/2PZiCHF1uKhYaUdHmcfydVzmdzcPLeUFPpSNM5agT9JYfY7MTYEouvM6AlZh9hflL qL9HYzGUezOHCQIyJtru1gU7tda89/oCUQaYUkqmBFfhTU41sc24UglPD7USmwgmWTcx 7VYUV9frl+CAiR6xfPHFGDiY4Cmbt88tZNIVqoD+ZKX/SLN4PrwGML369L1heoP2nIBJ XdHyrGAHTCDSOEpMqAEH6SwnLPvqVUIgUsst3lGclc7M1fc0w7f7n/TsHV/xSlDkL6Ho Fw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rw5k0j6ux-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2023 13:45:09 +0000 Received: from m0353722.ppops.net (m0353722.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 36HDhNbU030587; Mon, 17 Jul 2023 13:45:09 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rw5k0j6ua-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2023 13:45:09 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 36HAmOmX004479; Mon, 17 Jul 2023 13:45:08 GMT Received: from smtprelay03.dal12v.mail.ibm.com ([172.16.1.5]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3rv8g0tyvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2023 13:45:08 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay03.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36HDj6os54395370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Jul 2023 13:45:08 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A960A58065; Mon, 17 Jul 2023 13:45:06 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5E3FA58051; Mon, 17 Jul 2023 13:45:06 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTPS; Mon, 17 Jul 2023 13:45:06 +0000 (GMT) From: Jiufu Guo To: Richard Biener Cc: Andrew MacLeod , Aldy Hernandez , gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com, richard.sandiford@arm.com, segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com Subject: Re: [PATCH V4] Optimize '(X - N * M) / N' to 'X / N - M' if valid References: <20230711090413.3587421-1-guojiufu@linux.ibm.com> <430f2117-3848-d9e5-edab-607a58a460de@redhat.com> Date: Mon, 17 Jul 2023 21:45:04 +0800 In-Reply-To: (Richard Biener's message of "Mon, 17 Jul 2023 09:24:12 +0000 (UTC)") Message-ID: <7nsf9mzm73.fsf@ltcden2-lp1.aus.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: C0I7SESTdyHXEtQitpsqSIntI9QcwF_5 X-Proofpoint-GUID: A-nR8Ayo47COG22VkthHjGX9RASpOn69 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-17_11,2023-07-13_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 clxscore=1015 bulkscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307170123 X-Spam-Status: No, score=-4.8 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_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, Richard Biener writes: > On Fri, 14 Jul 2023, Andrew MacLeod wrote: > >>=20 >> On 7/14/23 09:37, Richard Biener wrote: >> > On Fri, 14 Jul 2023, Aldy Hernandez wrote: >> > >> >> I don't know what you're trying to accomplish here, as I haven't been >> >> following the PR, but adding all these helper functions to the ranger >> >> header >> >> file seems wrong, especially since there's only one use of them. I see >> >> you're >> >> tweaking the irange API, adding helper functions to range-op (which i= s only >> >> for code dealing with implementing range operators for tree codes), e= tc >> >> etc. >> >> >> >> If you need these helper functions, I suggest you put them closer to = their >> >> uses (i.e. wherever the match.pd support machinery goes). >> > Note I suggested the opposite beacuse I thought these kind of helpers >> > are closer to value-range support than to match.pd. >>=20 >>=20 >> probably vr-values.{cc.h} and=C2=A0 the simply_using_ranges paradigm wou= ld be the >> most sensible place to put these kinds of auxiliary routines? >>=20 >>=20 >> > >> > But I take away from your answer that there's nothing close in the >> > value-range machinery that answers the question whether A op B may >> > overflow? >>=20 >> we dont track it in ranges themselves.=C2=A0=C2=A0 During calculation of= a range we >> obviously know, but propagating that generally when we rarely care doesn= 't >> seem worthwhile.=C2=A0 The very first generation of irange 6 years ago h= ad an >> overflow_p() flag, but it was removed as not being worth keeping. =C2=A0= =C2=A0 easier >> to simply ask the question when it matters >>=20 >> As the routines show, it pretty easy to figure out when the need arises = so I >> think that should suffice.=C2=A0 At least for now, >>=20 >> Should we decide we would like it in general, it wouldnt be hard to add = to >> irange.=C2=A0 wi_fold() cuurently returns null, it could easily return a= bool >> indicating if an overflow happened, and wi_fold_in_parts and fold_range = would >> simply OR the results all together of the compoent wi_fold() calls.=C2= =A0 It would >> require updating/audfiting=C2=A0 a number of range-op entries and adding= an >> overflowed_p()=C2=A0 query to irange. > > Ah, yeah - the folding APIs would be a good fit I guess. I was > also looking to have the "new" helpers to be somewhat consistent > with the ranger API. > > So if we had a fold_range overload with either an output argument > or a flag that makes it return false on possible overflow that > would work I guess? Since we have a virtual class setup we > might be able to provide a default failing method and implement > workers for plus and mult (as needed for this patch) as the need > arises? Thanks for your comments! Here is a concern. The patterns in match.pd may be supported by 'vrp' passes. At that time, the range info would be computed (via the value-range machinery) and cached for each SSA_NAME. In the patterns, when range_of_expr is called for a capture, the range info is retrieved from the cache, and no need to fold_range again. This means the overflow info may also need to be cached together with other range info. There may be additional memory and time cost. BR, Jeff (Jiufu Guo) > > Thanks, > Richard.