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 C26853858D1E; Tue, 3 Jan 2023 03:28:47 +0000 (GMT) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3033NDxS004028; Tue, 3 Jan 2023 03:28:45 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; s=pp1; bh=w3qSTaFV1wYcm7SWDpQo/XHLYsMB3WAoJi+0hX56ArI=; b=IlmUfIRyWJqLMrwKsioJqAoznX2Q8zw3KqglxQa9Z52GcFgVF2vEC6fNpjBBoR4Q0ynS h/xjJCr2QTMn+KkhBi7wd59/lFwz7WwmvUpZThdlqABxqBtLlnbaInboMriiUUTb/bzo IH9HrtIrQDiHs/oyhrp2udf0NGtBKUKJnuouQHghNu0+AkbNkMstWQKykdkKFIZWM/Bk TrfxUXN1Visx2HrJm2x5S2ilMj/5YQMYUeT8oVeiEDcAQgV8PgOUzT1IXilcqHPoQre6 uxn1yMK4wSF6V4obgXx30XiCVqPhzrZAMDA+1DYHPPl/7z2BjT4oOZKrKipSCuxcb0x4 OQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mvcde01ue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2023 03:28:45 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3033SiRA020400; Tue, 3 Jan 2023 03:28:44 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mvcde01ub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2023 03:28:44 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3030WncP020292; Tue, 3 Jan 2023 03:28:43 GMT Received: from smtprelay02.dal12v.mail.ibm.com ([9.208.130.97]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3mtcq7bbdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2023 03:28:43 +0000 Received: from smtpav02.wdc07v.mail.ibm.com (smtpav02.wdc07v.mail.ibm.com [10.39.53.229]) by smtprelay02.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3033SgC530146818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Jan 2023 03:28:42 GMT Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7ECC65805C; Tue, 3 Jan 2023 03:28:42 +0000 (GMT) Received: from smtpav02.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CC38E5805B; Tue, 3 Jan 2023 03:28:41 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav02.wdc07v.mail.ibm.com (Postfix) with ESMTPS; Tue, 3 Jan 2023 03:28:41 +0000 (GMT) From: Jiufu Guo To: Andrew Pinski Cc: Segher Boessenkool , Jiufu Guo via Gcc-patches , Richard Biener , Richard Biener , dje.gcc@gmail.com, linkw@gcc.gnu.org, jeffreyalaw@gmail.com Subject: Re: [PATCH] loading float member of parameter stored via int registers References: <20221223165239.GA25951@gate.crashing.org> <20221223195207.GB25951@gate.crashing.org> <7ek02dft05.fsf@pike.rch.stglabs.ibm.com> <7e8ritexu0.fsf@pike.rch.stglabs.ibm.com> <7epmc1eil4.fsf@pike.rch.stglabs.ibm.com> <20221230074419.GE25951@gate.crashing.org> Date: Tue, 03 Jan 2023 11:28:38 +0800 In-Reply-To: (Andrew Pinski's message of "Fri, 30 Dec 2022 00:30:04 -0800") Message-ID: <7e7cy4e1p5.fsf@pike.rch.stglabs.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: -ZgHa8G18APNZzFY55TM-kB8njZLYccN X-Proofpoint-GUID: gnjp3Xb_P9aeTvssGzkaM3rB16bMBH0Z X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-02_14,2022-12-30_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 malwarescore=0 suspectscore=0 phishscore=0 mlxscore=0 bulkscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301030026 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,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, Andrew Pinski writes: > On Thu, Dec 29, 2022 at 11:45 PM Segher Boessenkool > wrote: >> >> Hi! >> >> On Fri, Dec 30, 2022 at 10:22:31AM +0800, Jiufu Guo wrote: >> > Considering the limitations of CSE, I try to find other places >> > to handle this issue, and notice DSE can optimize below code: >> > "[sfp:DI]=x:DI ; y:SI=[sfp:DI]" to "y:SI=x:DI#0". >> > >> > So, I drafted a patch to update DSE to handle DI->DF/SF. >> > The patch updates "extract_low_bits" to get mode change >> > with subreg. >> > >> > diff --git a/gcc/expmed.cc b/gcc/expmed.cc >> > index b12b0e000c2..5e36331082c 100644 >> > --- a/gcc/expmed.cc >> > +++ b/gcc/expmed.cc >> > @@ -2439,7 +2439,10 @@ extract_low_bits (machine_mode mode, machine_mode src_mode, rtx src) >> > >> > if (!targetm.modes_tieable_p (src_int_mode, src_mode)) >> > return NULL_RTX; >> > - if (!targetm.modes_tieable_p (int_mode, mode)) >> > + if (!targetm.modes_tieable_p (int_mode, mode) >> > + && !(known_le (GET_MODE_BITSIZE (mode), GET_MODE_BITSIZE (src_mode)) >> > + && GET_MODE_CLASS (mode) == MODE_FLOAT >> > + && GET_MODE_CLASS (src_mode) == MODE_INT)) >> > return NULL_RTX; >> > >> > src = gen_lowpart (src_int_mode, src); >> >> Ah! This simply shows rs6000_modes_tieable_p is decidedly non-optimal: >> it does not allow tying a scalar float to anything else. No such thing >> is required, or good apparently. I wonder why we have such restrictions >> at all in rs6000; is it just unfortunate history, was it good at one >> point in time? > > The documentation for TARGET_MODES_TIEABLE_P says the following: > If TARGET_HARD_REGNO_MODE_OK (r, mode1) and TARGET_HARD_REGNO_MODE_OK > (r, mode2) are always the same for any r, then TARGET_MODES_TIEABLE_P > (mode1, mode2) should be true. If they differ for any r, you should > define this hook to return false unless some other mechanism ensures > the accessibility of the value in a narrower mode. > > even though rs6000_hard_regno_mode_ok_uncached's comment has the following: > /* The float registers (except for VSX vector modes) can only hold floating > modes and DImode. */ > > TARGET_P8_VECTOR and TARGET_P9_VECTOR has special cased different modes now: > if (TARGET_P8_VECTOR && (mode == SImode)) > return 1; > > if (TARGET_P9_VECTOR && (mode == QImode || mode == HImode)) > return 1; > Which I suspect that means rs6000_modes_tieable_p should return true > for SImode and SFmode if TARGET_P8_VECTOR is true. Likewise for > TARGET_P9_VECTOR and SFmode and QImode/HImode too. > Thanks for your great comments! modes_tieable_p is invoked by a few places besides extract_low_bits, so updating this hook to relax the restriction may benefit more passes. We may update modes_tieable_p for more cases as possible. A hacked patch for "float vs. int" is listed at the end of this mail. While back to the issue of this PR: optimize float loading which is stored from the int register. DSE works more on basicblock, so updating modes_tieable_p (or extract_low_bits) can not handle some cases like: double __attribute__ ((noipa)) foo_df (DF arg, int flag) { if (flag == 2) return arg.a[3]; return 0.0; } I'm thinking a way to handle this case. BR, Jeff (Jiufu) > > Thanks, > Andrew Pinski > >> >> >> Segher (To be refined.) diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index b3a609f3aa3..8088a608be6 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -1959,6 +1959,17 @@ rs6000_hard_regno_mode_ok (unsigned int regno, machine_mode mode) static bool rs6000_modes_tieable_p (machine_mode mode1, machine_mode mode2) { + + if ((GET_MODE_CLASS (mode1) == MODE_FLOAT + && (GET_MODE_SIZE (mode2) == UNITS_PER_FP_WORD + || (TARGET_P8_VECTOR && (mode2 == SImode)) + || (TARGET_P9_VECTOR && (mode2 == QImode || mode2 == HImode)))) + || (GET_MODE_CLASS (mode2) == MODE_FLOAT + && (GET_MODE_SIZE (mode1) == UNITS_PER_FP_WORD + || (TARGET_P8_VECTOR && (mode1 == SImode)) + || (TARGET_P9_VECTOR && (mode1 == QImode || mode1 == HImode))))) + return true; + if (mode1 == PTImode || mode1 == OOmode || mode1 == XOmode || mode2 == PTImode || mode2 == OOmode || mode2 == XOmode) return mode1 == mode2; -------