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 17D0D3858430; Tue, 18 Jul 2023 09:44:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 17D0D3858430 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 (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36I9cjvl015941; Tue, 18 Jul 2023 09:44:34 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=BOMABiRMTdopGo7tNZH+qhnAaqKWDdA3wv7qQGIs8kM=; b=Wr+vfOTTfpl53AXk8is52ClUXf86VL2cz06Fm/OWkN0crchZVLn4dEQUpUP/7TexBeGG Hf50OpLG4TPc3vZvowuNaEq2AGS2Vs3YMwzoBSKQTbS8BGPYLubI9of/OclwLqXHqNZY yJIm9Xq7Wti0Dsoj5egGsbjWGbkXjuDREpSa3j6OslR9dPM69cBkLDzzTSgWyfftfGIg tVwcqjLtIrKvAWwBm/w+8jQVY3wcyl1OGPVJn9ThwwZUqIThbj+syO5ifvEN2FtDagd8 +1Jbu96gP9K+y9Lpa2V7jhKq71sG5HrmAPM9t62cuUqyADfpkn7FAJYgoYmiVSJ9qmGb AA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rwqws0mwm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2023 09:44:34 +0000 Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 36I9cs1L016435; Tue, 18 Jul 2023 09:44:33 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 3rwqws0mwa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2023 09:44:33 +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 36I8Mta3004156; Tue, 18 Jul 2023 09:44:33 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([172.16.1.69]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3rv8g0wd4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2023 09:44:33 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36I9iWKm52756932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Jul 2023 09:44:32 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F09265805A; Tue, 18 Jul 2023 09:44:31 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C44225805F; Tue, 18 Jul 2023 09:44:31 +0000 (GMT) Received: from ltcden2-lp1.aus.stglabs.ibm.com (unknown [9.3.90.43]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTPS; Tue, 18 Jul 2023 09:44:31 +0000 (GMT) From: Jiufu Guo To: Andrew MacLeod Cc: Richard Biener , 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> <7nsf9mzm73.fsf@ltcden2-lp1.aus.stglabs.ibm.com> Date: Tue, 18 Jul 2023 17:44:31 +0800 In-Reply-To: (Andrew MacLeod's message of "Mon, 17 Jul 2023 13:24:06 -0400") Message-ID: <7nilahzh8g.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: eHP2wDpS1eWFIiw4llRoqNuBTWQTx36i X-Proofpoint-GUID: S2EGSyZSrw7fxnYaTtEssRYeHPQRhCpQ 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_15,2023-07-13_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 spamscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307180087 X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,BODY_8BITS,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, Andrew MacLeod writes: > On 7/17/23 09:45, Jiufu Guo wrote: >> >>>> Should we decide we would like it in general, it wouldnt be hard to ad= d 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_rang= e 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 addi= ng 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. >> > > I've been thinking about this a little bit, and how to make the info avai= lable in a useful way. > > I wonder if maybe we just add another entry point=C2=A0 to range-ops that= looks a bit like fold_range .. > > =C2=A0 Attached is an (untested) patch which ads overflow_free_p(op1, op2, > relation)=C2=A0 to rangeops.=C2=A0=C2=A0 It defaults to returning false.= =C2=A0 If you want > to implement it for say plus,=C2=A0 you'd add to operator_plus in > range-ops.cc=C2=A0 something like > > operator_plus::overflow_free_p (irange&op1, irange& op2, relation_kind) > { > =C2=A0=C2=A0 // stuff you do in plus_without_overflow > } > > I added relation_kind as=C2=A0 param, but you can ignore it.=C2=A0 maybe = it wont > ever help, but it seems like if we know there is a relation between > op1 and op2 we might be able to someday determine something else?=C2=A0= =C2=A0=C2=A0=C2=A0 > if not, remove it. > > Then all you need to do too access it is to go thru range-op_handler.. so= for instance: > > range_op_handler (PLUS_EXPR).overflow_free_p (op1, op2) > > It'll work for all types an all tree codes. the dispatch machinery > will return false unless both op1 and op2 are integral ranges, and > then it will invoke the appropriate handler, defaulting to returning > FALSE. Very good suggestions! Thanks so much for your great guide! > > I also am not a fan of the get_range=C2=A0 routine.=C2=A0 It would be bet= ter to > generally just call range_of_expr, get the results, then handle > undefined in the new overflow_free_p() routine and return false.=C2=A0 > varying should not need anything special since it will trigger the > overflow when you do the calculation. The general code in the trunk is just like you said: range_of_expr is used when querying a range for an expr. I am also aware that: a range with varying([min, max]) may be ok if the range is computed from other ranges, especially if there is no overflow. For example, '[MAX-100, MAX] - [0, 100]' generates a varying range, but it would be ok for some case. And a varying range will trigger overflow if it takes part in a calculation as your said. So, I agree that varying would not be specially for some patterns. > > The auxillary routines could go in vr-values.h/cc.=C2=A0 They seem like > things that simplify_using_ranges could utilize, and when we get to > integrating simplify_using_ranges better,=C2=A0 what you are doing may end > up there anyway Thanks for your suggestion! Or maybe we could just use the APIs=20 in match.pd directly. > > Does that work? I believe this would work! I will submit a new version patch! Thanks again for your comments! BR, Jeff (Jiufu Guo) > > Andrew