Message ID | 3b0984ef-c532-c29c-732a-1c9b569e134c@linux.ibm.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5044:0:0:0:0:0 with SMTP id h4csp1174941wrt; Wed, 7 Sep 2022 07:40:51 -0700 (PDT) X-Google-Smtp-Source: AA6agR4QlQMRFRegijim3rMsDLNQJnuj0II8RKfCiatO0drdX8MnxJFRUwIeiQwOIQIVt4Z1a6YA X-Received: by 2002:a05:6402:4282:b0:43e:612c:fcf7 with SMTP id g2-20020a056402428200b0043e612cfcf7mr3332968edc.242.1662561651815; Wed, 07 Sep 2022 07:40:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662561651; cv=none; d=google.com; s=arc-20160816; b=diVY0uFA9PHpUuKLE43JpeUzUFVywgSGuqvnc+GYyaroUgbtS0a68UfC8ANp9q0pf6 rgzxdJXHim6yUv9CYRJsmnjmZ8yyf8Ddh9EUw21GQ+O42Qzn1Zqgmj1+2yaB6atJzzBp mWZmcFYMYThJwGJX1NVEoMYtDc86scKRckNDqJlbVzD2QX54CaUKmh8BYy74TlEwBkJE Rjek7q/BtmHdJYzoGhFCgGKDti3wUw2K0ktqiubCLTR8IDHPpglD9eMGwylGRy2Nq5G+ 5/iTGCyTJdWZSDDeHsSwWOgN6W+rVZfHNcEWupezbJWJkc4FqPQ7MqZrEcjVotn1+b5C 9y4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:subject:to:content-language:user-agent :mime-version:date:message-id:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=1/vsfpvE9XENGiYFNFV2SRyP5ptZ7WmTNpnkFH6D0FY=; b=xo8nIgYnMcILN86Goo0To1aC0Ne7HZq3W+ssbiXHX0VwnSTZF8nBvZMSYlaVPAtBMQ OllyOyMHKiPkirzplafRB7/JAt4POF+MHTW2EEukrVh/R6LETkSg4tA3GR9C92Oyt0Wq gjvHaTEs2wQmZ6FkJ4KXImaEEtqRbVjSPt7jeXOb2kV1dMT9Ux7nac9GPqTVslZA40SB r/viHd2tdym6TrdVCAg8w3yUcgDKC98qx18TvGare/ZDGE+I6uaA0jIzr74UFx5TCktf tufrOldF5YkoVs550okm/sWMykVef8+kK2r952FQprOxPuGIN0sunXGiDIRpteT7Gp1X Lp6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=lxO4Q9nU; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id u26-20020a50c2da000000b00448b28cac97si11325912edf.305.2022.09.07.07.40.51 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 07:40:51 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=lxO4Q9nU; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9CE9B3850874 for <ouuuleilei@gmail.com>; Wed, 7 Sep 2022 14:40:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9CE9B3850874 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1662561650; bh=1/vsfpvE9XENGiYFNFV2SRyP5ptZ7WmTNpnkFH6D0FY=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=lxO4Q9nU19yZ6cBF6lvJQcTOYrT/oYueoDGyWo7fz0lkIofOWXGep4p0y5o9zlRpF bm9qC9a18PmMsf6cwOI0L3+H2EbGDL4NvYQrpX/jZaQH5hCxGQXcLBWUYcn9d6AgGI ex8DhHfYI4QJFebOLAKpnGwOM0EOwPkCaxBPpipc= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 76F263858403 for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76F263858403 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 287EILsj022183 for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:07 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jevxtgs3s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <gcc-patches@gcc.gnu.org>; Wed, 07 Sep 2022 14:40:06 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 287EaAn0023702 for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:05 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma01fra.de.ibm.com with ESMTP id 3jbxj8uxms-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <gcc-patches@gcc.gnu.org>; Wed, 07 Sep 2022 14:40:04 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 287Ee2oV39453016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:02 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8E042A4059 for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:02 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A5C1A404D for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:02 +0000 (GMT) Received: from [9.171.19.250] (unknown [9.171.19.250]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS for <gcc-patches@gcc.gnu.org>; Wed, 7 Sep 2022 14:40:02 +0000 (GMT) Message-ID: <3b0984ef-c532-c29c-732a-1c9b569e134c@linux.ibm.com> Date: Wed, 7 Sep 2022 16:40:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US To: GCC Patches <gcc-patches@gcc.gnu.org> Subject: [RFC] postreload cse'ing vector constants Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: A-Yr7vda_jZwjfcBT3--cmcgzvb2wzFz X-Proofpoint-GUID: A-Yr7vda_jZwjfcBT3--cmcgzvb2wzFz X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-07_08,2022-09-07_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxscore=0 phishscore=0 spamscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 impostorscore=0 priorityscore=1501 bulkscore=0 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2209070057 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H2, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Robin Dapp via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Robin Dapp <rdapp@linux.ibm.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1743322246524551045?= X-GMAIL-MSGID: =?utf-8?q?1743322246524551045?= |
Series |
[RFC] postreload cse'ing vector constants
|
|
Commit Message
Robin Dapp
Sept. 7, 2022, 2:40 p.m. UTC
Hi, I recently looked into a sequence like vzero %v0 vlr %v2, %v0 vlr %v3, %v0. Ideally we would like to use vzero for all of these sets in order to not create dependencies. For some instances of this problem I found the offending snippet to be the postreload cse pass. If there is a non hard reg whose value is equivalent to an existing hard reg, it will replace the non hard reg. The costs are only compared if the respective operand is a CONST_INT_P, otherwise we always replace. The comment before says: /* See if REGNO fits this alternative, and set it up as the replacement register if we don't have one for this alternative yet and the operand being replaced is not a cheap CONST_INT. */ Now, in my case we have a CONST_VECTOR consisting of CONST_INTS (zeros). This is obviously no CONST_INT therefore the substitution takes place resulting in a "vlr" instead of a "vzero". Would it not make sense to always compare costs here? Some backends have instructions for loading vector constants and there could also be backends able to load floating point constants directly. For my snippet getting rid of the CONST_INT check suffices because the costs are similar and no replacement happens. Was this originally a shortcut for performance reasons? I thought we were not checking that many alternatives and only locally at this point anymore. Any comments or ideas? Regards Robin -- op_alt_regno[i][j] = regno;
Comments
On 9/7/2022 8:40 AM, Robin Dapp via Gcc-patches wrote: > Hi, > > I recently looked into a sequence like > > vzero %v0 > vlr %v2, %v0 > vlr %v3, %v0. > > Ideally we would like to use vzero for all of these sets in order to not > create dependencies. > > For some instances of this problem I found the offending snippet to be > the postreload cse pass. If there is a non hard reg whose value is > equivalent to an existing hard reg, it will replace the non hard reg. > The costs are only compared if the respective operand is a CONST_INT_P, > otherwise we always replace. > > The comment before says: > /* See if REGNO fits this alternative, and set it up as the > > > replacement register if we don't have one for this > > > alternative yet and the operand being replaced is not > > > a cheap CONST_INT. */ > > Now, in my case we have a CONST_VECTOR consisting of CONST_INTS (zeros). > This is obviously no CONST_INT therefore the substitution takes place > resulting in a "vlr" instead of a "vzero". > Would it not make sense to always compare costs here? Some backends have > instructions for loading vector constants and there could also be > backends able to load floating point constants directly. > > For my snippet getting rid of the CONST_INT check suffices because the > costs are similar and no replacement happens. Was this originally a > shortcut for performance reasons? I thought we were not checking that > many alternatives and only locally at this point anymore. > > Any comments or ideas? It looks sensible to me. ISTM this should be driven by costs, not by any particular rtx codes. Your patch takes things in the right direction. Did you did any archeology into this code to see if there was any history that might shed light on why it doesn't just using the costing models? jeff
> Did you did any archeology into this code to see if there was any > history that might shed light on why it doesn't just using the costing > models? This one was buried under some dust :) commit 0254c56158b0533600ba9036258c11d377d46adf Author: John Carr <jfc@mit.edu> Date: Wed Jun 10 06:00:50 1998 +0000 reload1.c (reload_cse_simplify_operands): Do not call gen_rtx_REG for each alternative. Wed Jun 10 08:56:27 1998 John Carr <jfc@mit.edu> * reload1.c (reload_cse_simplify_operands): Do not call gen_rtx_REG for each alternative. Do not replace a CONST_INT with a REG unless the reg is cheaper. From-SVN: r20402 Back then we didn't have vectors I suppose but apart from that I don't see a compelling reason not to unconditionally check costs from this. It seems like we did even more unconditional replacing before it, including CONST_INTs. Regards Robin
On 9/7/2022 9:33 AM, Robin Dapp wrote: >> Did you did any archeology into this code to see if there was any >> history that might shed light on why it doesn't just using the costing >> models? > This one was buried under some dust :) > > commit 0254c56158b0533600ba9036258c11d377d46adf > Author: John Carr <jfc@mit.edu> > Date: Wed Jun 10 06:00:50 1998 +0000 > > reload1.c (reload_cse_simplify_operands): Do not call gen_rtx_REG > for each alternative. > > Wed Jun 10 08:56:27 1998 John Carr <jfc@mit.edu> > * reload1.c (reload_cse_simplify_operands): Do not call > gen_rtx_REG > for each alternative. Do not replace a CONST_INT with a REG > unless > the reg is cheaper. > > From-SVN: r20402 > > Back then we didn't have vectors I suppose but apart from that I don't > see a compelling reason not to unconditionally check costs from this. > It seems like we did even more unconditional replacing before it, > including CONST_INTs. Which is this from the mail archives: https://gcc.gnu.org/pipermail/gcc-patches/1998-June/000308.html I would tend to agree that for equal cost that the constant would be preferred since that should be better from a scheduling/dependency standpoint. So it seems to me we can drive this purely from a costing standpoint. jef
> Which is this from the mail archives: > > https://gcc.gnu.org/pipermail/gcc-patches/1998-June/000308.html > > I would tend to agree that for equal cost that the constant would be > preferred since that should be better from a scheduling/dependency > standpoint. So it seems to me we can drive this purely from a costing > standpoint. I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9 and s390. Everything looks good except two additional fails on x86 where code actually looks worse. gcc.target/i386/keylocker-encodekey128.c 17c17,18 < movaps %xmm4, k2(%rip) --- > pxor %xmm0, %xmm0 > movaps %xmm0, k2(%rip) gcc.target/i386/keylocker-encodekey256.c: 19c19,20 < movaps %xmm4, k3(%rip) --- > pxor %xmm0, %xmm0 > movaps %xmm0, k3(%rip) Regards Robin
> I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9 > and s390. Everything looks good except two additional fails on x86 > where code actually looks worse. > > gcc.target/i386/keylocker-encodekey128.c > > 17c17,18 > < movaps %xmm4, k2(%rip) > --- >> pxor %xmm0, %xmm0 >> movaps %xmm0, k2(%rip) > > gcc.target/i386/keylocker-encodekey256.c: > > 19c19,20 > < movaps %xmm4, k3(%rip) > --- >> pxor %xmm0, %xmm0 >> movaps %xmm0, k3(%rip) Before the patch and after postreload we have: (insn (set (reg:V2DI xmm0) (reg:V2DI xmm4)) (expr_list:REG_DEAD (reg:V2DI 24 xmm4) (expr_list:REG_EQUIV (const_vector:V2DI [ (const_int 0 [0]) repeated x2 ]))))) (insn (set (mem/c:V2DI (symbol_ref:DI ("k2")) (reg:V2DI xmm0)))) which is converted by cprop_hardreg to: (insn (set (mem/c:V2DI (symbol_ref:DI ("k2"))) (reg:V2DI xmm4)))) With the change there is: (insn (set (reg:V2DI xmm0) (const_vector:V2DI [ (const_int 0 [0]) repeated x2 ]))) (insn (set (mem/c:V2DI (symbol_ref:DI ("k2"))) (reg:V2DI xmm0)))) which is not simplified further because xmm0 needs to be explicitly zeroed while xmm4 is assumed to be zeroed by encodekey128. I'm not familiar with this so I'm supposing this is correct even though I found "XMM4 through XMM6 are reserved for future usages and software should not rely upon them being zeroed." online. Even inf xmm4 were zeroed explicity, I guess in this case the simple costing of mov reg,reg vs mov reg,imm (with the latter not being more expensive) falls short? cprop_hardreg can actually propagate the zeroed xmm4 into the next move. The same mechanism could possibly even elide many such moves which would mean we'd unnecessarily emit many mov reg,0? Hmm...
On Tue, Sep 27, 2022 at 10:46 AM Robin Dapp via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9 > > and s390. Everything looks good except two additional fails on x86 > > where code actually looks worse. > > > > gcc.target/i386/keylocker-encodekey128.c > > > > 17c17,18 > > < movaps %xmm4, k2(%rip) > > --- > >> pxor %xmm0, %xmm0 > >> movaps %xmm0, k2(%rip) > > > > gcc.target/i386/keylocker-encodekey256.c: > > > > 19c19,20 > > < movaps %xmm4, k3(%rip) > > --- > >> pxor %xmm0, %xmm0 > >> movaps %xmm0, k3(%rip) > > Before the patch and after postreload we have: > > (insn (set (reg:V2DI xmm0) > (reg:V2DI xmm4)) > (expr_list:REG_DEAD (reg:V2DI 24 xmm4) > (expr_list:REG_EQUIV (const_vector:V2DI [ > (const_int 0 [0]) repeated x2 > ]))))) > (insn (set (mem/c:V2DI (symbol_ref:DI ("k2")) > (reg:V2DI xmm0)))) > > which is converted by cprop_hardreg to: > > (insn (set (mem/c:V2DI (symbol_ref:DI ("k2"))) > (reg:V2DI xmm4)))) > > With the change there is: > > (insn (set (reg:V2DI xmm0) > (const_vector:V2DI [ > (const_int 0 [0]) repeated x2 > ]))) > (insn (set (mem/c:V2DI (symbol_ref:DI ("k2"))) > (reg:V2DI xmm0)))) > > which is not simplified further because xmm0 needs to be explicitly > zeroed while xmm4 is assumed to be zeroed by encodekey128. I'm not > familiar with this so I'm supposing this is correct even though I found > "XMM4 through XMM6 are reserved for future usages and software should > not rely upon them being zeroed." online. I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061 > Even inf xmm4 were zeroed explicity, I guess in this case the simple > costing of mov reg,reg vs mov reg,imm (with the latter not being more > expensive) falls short? cprop_hardreg can actually propagate the zeroed > xmm4 into the next move. > The same mechanism could possibly even elide many such moves which would > mean we'd unnecessarily emit many mov reg,0? Hmm... This sounds like an issue.
> I opened: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107061 The online docs for encodekey256 also say XMM4 through XMM6 are reserved for future usages and software should not rely upon them being zeroed. I believe we also zero there. > This sounds like an issue. So with your patch for encodekey128 the regression is gone and we zero (pxor) xmm0 in both versions. The case I outlined before does not actually happen since cprop_hardreg propagates the (newly) zeroed register to the use sites rather than zeroing every time. I guess this just leaves the situation where we implicitly know that a reg is zero and by rather zeroing another one we miss the cprop_hardreg opportunity. Not sure how common this is and if it's a blocker for this patch. No regressions on x86, aarch64, power9 and s390 now. Most likely we don't check to that granularity in the test suite and even here it was more of accidental hit.
Should we go ahead with this, i.e. push the change and wait for fallout? I guess we're still early enough in the cycle for that. There are no regressions anymore on s390, Power9, x86 and aarch64 (at least on the farm machines I checked). Regards Robin
On 11/3/22 06:38, Robin Dapp wrote: > Should we go ahead with this, i.e. push the change and wait for fallout? > I guess we're still early enough in the cycle for that. There are no > regressions anymore on s390, Power9, x86 and aarch64 (at least on the > farm machines I checked). That would be my recommendation (go forward asap so that there's more time to find any fallout). jeff
diff --git a/gcc/postreload.cc b/gcc/postreload.cc index 41f61d326482..934439733d52 100644 --- a/gcc/postreload.cc +++ b/gcc/postreload.cc @@ -558,13 +558,12 @@ reload_cse_simplify_operands (rtx_insn *insn, rtx testreg) if (op_alt_regno[i][j] == -1 && TEST_BIT (preferred, j) && reg_fits_class_p (testreg, rclass, 0, mode) - && (!CONST_INT_P (recog_data.operand[i]) - || (set_src_cost (recog_data.operand[i], mode, - optimize_bb_for_speed_p - (BLOCK_FOR_INSN (insn))) - > set_src_cost (testreg, mode, - optimize_bb_for_speed_p - (BLOCK_FOR_INSN (insn)))))) + && (set_src_cost (recog_data.operand[i], mode, + optimize_bb_for_speed_p + (BLOCK_FOR_INSN (insn))) + > set_src_cost (testreg, mode, + optimize_bb_for_speed_p + (BLOCK_FOR_INSN (insn))))) { alternative_nregs[j]++;