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 9C3513858D3C; Wed, 11 Jan 2023 03:48:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C3513858D3C 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 (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30B2CWZ5012367; Wed, 11 Jan 2023 03:48:28 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=YAsPVkT8Iri5wtURLR7Ym6hDT8fRklYsfFFgTw7HyXA=; b=oiJBzgyixGlSaiNoIlXiqlQ9ZNefHuEabMlT3jWVrvJ6pC//vPWBaiVDKCtPOpT/iV2I 39p1kJfbZifX7oVYgolJNX/Wz+cfs77zcUGP78U+XEnYsmDeFHFUaVnYSKmZdgX4+bNa mhlo3rf/vg7W3E/DEbq8T1bBxJFK+S0zauaVXpSpcQHjN20xQBFPfF2bBpPhaUuDyZ32 pRATRqqiZ3HQ4FKJn8fRQObuINgm936oDmArJZMC5Kb8UnYusEUqrlcRrUvDe6/ysY0d YETc/9wAQplGyvRJN/bCtDAbZamlQSpBviTRt3OA/IEjHM1gs+TQQgdtaybtpJEK8e8l RQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n1m4k1dph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jan 2023 03:48:28 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30B3LFY4015262; Wed, 11 Jan 2023 03:48:27 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n1m4k1dp1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jan 2023 03:48:27 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30B1ZdPA004588; Wed, 11 Jan 2023 03:48:26 GMT Received: from smtprelay01.wdc07v.mail.ibm.com ([9.208.129.119]) by ppma05wdc.us.ibm.com (PPS) with ESMTPS id 3n1kk78g1k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jan 2023 03:48:26 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay01.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30B3mOh539977518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Jan 2023 03:48:24 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6EBAD58066; Wed, 11 Jan 2023 03:48:24 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3ADC15805A; Wed, 11 Jan 2023 03:48:24 +0000 (GMT) Received: from pike (unknown [9.5.12.127]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTPS; Wed, 11 Jan 2023 03:48:24 +0000 (GMT) From: Jiufu Guo To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org Subject: Re: [PATCH] rs6000: Enhance lowpart/highpart DI->SF by mtvsrws/mtvsrd References: <20230110134527.194389-1-guojiufu@linux.ibm.com> <20230110142245.GR25951@gate.crashing.org> Date: Wed, 11 Jan 2023 11:48:22 +0800 In-Reply-To: <20230110142245.GR25951@gate.crashing.org> (Segher Boessenkool's message of "Tue, 10 Jan 2023 08:22:45 -0600") Message-ID: <7eh6wxd94p.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-GUID: f2XrQDK8EEb6EWXRSz1YBK4a_xn9NVtl X-Proofpoint-ORIG-GUID: cWaENJYB_cRPclecrmZlmit09_rV4OEx X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2023-01-10_10,2023-01-10_03,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 adultscore=0 clxscore=1015 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301110025 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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 your help to review! Segher Boessenkool writes: > Hi! > > On Tue, Jan 10, 2023 at 09:45:27PM +0800, Jiufu Guo wrote: >> As mentioned in PR108338, on p9, we could use mtvsrws to implement >> the conversion from SI#0 to SF (or lowpart DI to SF). And we find >> we can also enhance the conversion from highpart DI to SF (as the >> case in this patch). >> >> This patch enhances these conversions accordingly. > > Those aren't conversions, they are just bitcasts, reinterpreting the > same datum as something else, but keeping all bits the same. Yeap, bitcast is accurate. > > The mtvsrws insn moves a SImode value from a GPR to a VSR, splatting it > in all four lanes. You'll typically want a xscvspdpn or similar after > that -- but with the value splat in all lanes it will surely be in the > lane that later instruction needs the data to be in :-) Right. xscvspdpn is needed typically. > >> --- a/gcc/config/rs6000/rs6000.md >> +++ b/gcc/config/rs6000/rs6000.md >> @@ -158,6 +158,7 @@ (define_c_enum "unspec" >> UNSPEC_HASHCHK >> UNSPEC_XXSPLTIDP_CONST >> UNSPEC_XXSPLTIW_CONST >> + UNSPEC_P9V_MTVSRWS >> ]) > > Is it hard to decribe this without unspec? Unspecs prevent the compiler > from optimising things (unless you very carefully implement all of that > manually -- but if you just write it as plain RTL most things fall into > place automatically). > > There are many existing patterns that needlessly and detrimentally use > unspecs, but we should improve on that, not make it worse :-) Thanks for pointing out this! I also notice this. Some patterns for bitcast int->float are also using unspecs. For example, in expand pass: (set (reg:SF 117 [ ]) (unspec:SF [ (reg:SI 121) ] UNSPEC_SF_FROM_SI)) it is "movsf_from_si" which is generated for "BIT_FIELD_REF ". "movsf_from_si2" is also using unspec. And clobbers is used in "movsf_from_si". While they may be not needed for some cases. I'm wondering if "TARGET_NO_SF_SUBREG" is accurated for those patterns. /* Whether we should avoid (SUBREG:SI (REG:SF) and (SUBREG:SF (REG:SI). */ #define TARGET_NO_SF_SUBREG TARGET_DIRECT_MOVE_64BIT #define TARGET_ALLOW_SF_SUBREG (!TARGET_DIRECT_MOVE_64BIT) We may allow (SUBREG:SF (REG:SI) at early passes, and keep it untill later passes (RA/reload, or splitter) at least. In this patch, to avoid risk and make it straightforward, I define a new insn 'mtvsrws' with unspec. I would try another ways to avoid using unspec. Maybe keep to use subreg pattern: "(set (reg:SF 117) (subreg:SF (reg/v:SI 118) 0))"? > >> @@ -8203,10 +8204,19 @@ (define_insn_and_split "movsf_from_si" >> rtx op2 = operands[2]; >> rtx op1_di = gen_rtx_REG (DImode, REGNO (op1)); >> >> - /* Move SF value to upper 32-bits for xscvspdpn. */ >> - emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32))); >> - emit_insn (gen_p8_mtvsrd_sf (op0, op2)); >> - emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0)); >> + if (TARGET_P9_VECTOR && TARGET_POWERPC64 && TARGET_DIRECT_MOVE) >> + { >> + emit_insn (gen_p9_mtvsrws (op0, op1_di)); >> + emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0)); >> + } > > This does not require TARGET_POWERPC64? Oh, accurately speaking: 'mtvsrws' is using 32bit only. :) > > P9 implies we have direct moves (those are implied by P8 already). We > also do not need to test for vector I think? Adding TARGET_P9_VECTOR, because I think, 'mtvsrws' operates on vector register. (Or just treat them as FP regiters? But I feel it seems more accurate vector registers.) We have TARGET_DIRECT_MOVE_128 defined for P9: "(TARGET_P9_VECTOR && TARGET_DIRECT_MOVE && TARGET_POWERPC64)" like "TARGET_DIRECT_MOVE_64BIT" for P8. So, we still need TARGET_DIRECT_MOVE, right? > >> +(define_code_iterator any_rshift [ashiftrt lshiftrt]) >> + >> ;; For extracting high part element from DImode register like: >> ;; {%1:SF=unspec[r122:DI>>0x20#0] 86;clobber scratch;} >> ;; split it before reload with "and mask" to avoid generating shift right >> ;; 32 bit then shift left 32 bit. >> -(define_insn_and_split "movsf_from_si2" >> +(define_insn_and_split "movsf_from_si2_" >> [(set (match_operand:SF 0 "gpc_reg_operand" "=wa") >> (unspec:SF >> [(subreg:SI >> - (ashiftrt:DI >> + (any_rshift:DI >> (match_operand:DI 1 "input_operand" "r") >> (const_int 32)) >> 0)] > > Hrm. You can write this with just a subreg, no shift is needed at all. > Can you please try that instead? That is nastiness for endianness, but > that is still preferable over introducing new complexities like this. Currently, this define_insn_and_split would be used to combine "shift;subreg"; because "highpart subreg DI->SF" is expanded to "rightshift:DI 32 ; lowpart subreg:DI->SI; SI#0->SF". It seems, we are not in favor of generating highpart subreg. :) While I agree with you: this is just a subreg (lowpart for BE, highpart for LE), and current patterns seem too complex. > >> +(define_insn "p9_mtvsrws" >> + [(set (match_operand:SF 0 "register_operand" "=wa") >> + (unspec:SF [(match_operand:DI 1 "register_operand" "r")] >> + UNSPEC_P9V_MTVSRWS))] >> + "TARGET_P9_VECTOR && TARGET_POWERPC64 && TARGET_DIRECT_MOVE" >> + "mtvsrws %x0,%1" >> + [(set_attr "type" "mtvsr")]) > > (Same issues here as above). Understand. I will try to update. > >> +/* { dg-final { scan-assembler-times {\mmtvsrws\M} 1 { target { has_arch_ppc64 && has_arch_pwr9 } } } } */ > > mtvsrws does not need ppc64. > >> +/* { dg-final { scan-assembler-times {\mmtvsrd\M} 1 { target { has_arch_ppc64 && has_arch_pwr9 } } } } */ >> +/* { dg-final { scan-assembler-times {\mrldicr\M} 1 { target { has_arch_ppc64 && has_arch_pwr9 } } } } */ > > These two do of course. > >> +/* { dg-final { scan-assembler-times {\mxscvspdpn\M} 2 { target { has_arch_pwr8 && has_arch_ppc64 } } } } */ > > But this doesn't. I think I get your thoughts. Align the condition in code, we may update "TARGET_P9_VECTOR && TARGET_POWERPC64 && TARGET_DIRECT_MOVE" to be accurately. BR, Jeff (Jiufu) > > > Segher