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 EBDE7385840E for ; Mon, 22 Nov 2021 21:12:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBDE7385840E Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1AMKMQmH032320; Mon, 22 Nov 2021 21:12:24 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3cgj6b0xfw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Nov 2021 21:12:24 +0000 Received: from m0098416.ppops.net (m0098416.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1AMKtcqF012589; Mon, 22 Nov 2021 21:12:23 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0b-001b2d01.pphosted.com with ESMTP id 3cgj6b0xfq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Nov 2021 21:12:23 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1AML2tOs007720; Mon, 22 Nov 2021 21:12:23 GMT Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by ppma05wdc.us.ibm.com with ESMTP id 3cerna6y47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Nov 2021 21:12:23 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1AMLCMmX67043778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Nov 2021 21:12:22 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EDBE62805E; Mon, 22 Nov 2021 21:12:21 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 693372805C; Mon, 22 Nov 2021 21:12:21 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.160.125.84]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTPS; Mon, 22 Nov 2021 21:12:21 +0000 (GMT) Date: Mon, 22 Nov 2021 16:12:19 -0500 From: Michael Meissner To: Bill Schmidt Cc: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner , Will Schmidt Subject: Re: [PATCH 1/3] Add power10 zero cycle moves for switches & indirect jumps Message-ID: Mail-Followup-To: Michael Meissner , Bill Schmidt , gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner , Will Schmidt References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: rmMFRvED2latxb7GkQDT-V6egsx88cwv X-Proofpoint-ORIG-GUID: 54VE3rhbo7DQ_ga6pxOxyQuaw0sEzLih X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-22_08,2021-11-22_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015 phishscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111220106 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 21:12:26 -0000 On Mon, Nov 22, 2021 at 10:36:13AM -0600, Bill Schmidt wrote: > Hi Mike, > > Thanks for this patch! > > --- a/gcc/config/rs6000/rs6000.md > > +++ b/gcc/config/rs6000/rs6000.md > > @@ -12988,15 +12988,34 @@ (define_expand "indirect_jump" > > emit_jump_insn (gen_indirect_jump_nospec (Pmode, operands[0], ccreg)); > > DONE; > > } > > + if (TARGET_P10_FUSION && TARGET_P10_FUSION_ZERO_CYCLE) > > + { > > + emit_jump_insn (gen_indirect_jump_zero_cycle (Pmode, operands[0])); > > + DONE; > > + } > > }) > > > > (define_insn "*indirect_jump" > > [(set (pc) > > (match_operand:P 0 "register_operand" "c,*l"))] > > - "rs6000_speculate_indirect_jumps" > > + "rs6000_speculate_indirect_jumps > > + && !(TARGET_P10_FUSION && TARGET_P10_FUSION_ZERO_CYCLE)" > > "b%T0" > > [(set_attr "type" "jmpreg")]) > > > > +(define_insn "@indirect_jump_zero_cycle" > > I don't know why this is an "@" pattern, but honestly I don't > know why @indirect_jump_nospec is an "@" pattern either. > The documentation for such things is hard for me to understand, > so I'm probably just missing something obvious, but I don't > immediately see why we would need the @ here. I didn't know about it either. Basically the next insn used it: (define_insn "@indirect_jump_nospec" [(set (pc) (match_operand:P 0 "register_operand" "c,*l")) (clobber (match_operand:CC 1 "cc_reg_operand" "=y,y"))] "!rs6000_speculate_indirect_jumps" "crset %E1\;beq%T0- %1\;b $" [(set_attr "type" "jmpreg") (set_attr "length" "12")]) This creates a function: gen_indirect_jump_nospec (machine_mode arg0, rtx x0, rtx x1) where the mode of the P iterator is passed as argument. I.e. you can do: rtx foo = gen_indirect_jump_nospec (Pmode, op0, op1); instead of: rtx foo; if (Pmode == SImode) foo = gen_indirect_jumpsi_nospec (op0, op1); else if (Pmode == DImode) foo = gen_indirect_jumpdi_nospec (op0, op1); else gcc_unreachable (); > > + [(set (pc) > > + (match_operand:P 0 "register_operand" "r,r,!cl")) > > + (clobber (match_scratch:P 1 "=c,*l,X"))] > > Do we need the *l and X alternatives if we're only doing this for > mtctr/bctr? Probably not, but I recall back before the current allocator, that it would cause crashes if we didn't have LR. I could certainly eliminate the *l alternative. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meissner@linux.ibm.com