From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonicconh5003-vm0.mail.kks.yahoo.co.jp (sonicconh5003-vm0.mail.kks.yahoo.co.jp [114.110.61.43]) by sourceware.org (Postfix) with ESMTPS id 1018D385840E for ; Thu, 12 Jan 2023 03:34:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1018D385840E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=yahoo.co.jp Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.co.jp X-YMail-OSG: AxCn8rgVM1neVloHHe5mdA9sg8qxmdX6OREliyNAqkX8uPfLoUgc93e4XFsuWET N0b07XCaW5nm.wUNSsilIbciQ6iCP_ojv.U.rpHbu8OPUMAbmnX09ShmJQcsNojaWnufNRtnet21 OZSv0agkzF7XECBj7AfjBucta3lt6T.3hIp4J9vYWEqENkF2R_BxNEUyK3nnx2MzUscmtrr2NTk6 2fWJvIIaRmyw5reUkH7iMdOxLloiQY2P1UIvY6yirqJS1PL3G1xl5Zw1sDbmIeQ9cPzLjTptFrt2 g.Yt0gxikbin.yOnYBSDu2.C4ZtwTk9sTq_E17d.eWGLnEWc9f.JiaBB.F3laWDVOC.bgoBPAGRc sXa9cRTf.N7WVJqGArxUJmFkSk_Ch5xowfw_.mjj62OQ6wo_e.nsbhkxF3_4rnMwJxf4x6bBEmBd kGx9axRspIDCXUK_PkLmLoW8Pk8R9pvMElJK8Yp2UA30g0G93P1h.bqyCgQF0pxNxbe8PYjYIGdH PuDrXEwZNBtpPmKe1Qw_ib_a_7ZmpaZZAdnqBGtdEn5LMFE1rCjBhXw__k.ZRGdEmHawGNFVGsFf R3sWUczeo9muAXr070jVzJ4Hsyo4xhDct6iBABEn1_Am4Kr7nM06JUwoNP09_sxDsgBy7rfkeJP5 TJs_5j.xAUnB0jEhDdnblP1UJ2uV_hHXChJpNDar5sA__Sqg5nhbiDI7vYEKrG_noZrtj7vSQJAy 25K8jeKjEc2lszuKJ6707IUPH5y6DiGczukz9qyRuaXq6DsuB1tXi_ekG9qUvRgvqAMdnwuuePI6 nzEKWLN_JV6hpSzxx25JWhZ.m0KetLjZe0zusOEPkrO3wjJha7Ybgs2fSvEtQd1JG7MIl2crRDG7 2k3GMmrBaxtVerhltBpe80teuLSWVk_KWIwHl1cDm8X88NIEOL9PjMw.CBiMCYMjiotClkDyRKtY 0JSl47dDt Received: from sonicgw.mail.yahoo.co.jp by sonicconh5003.mail.kks.yahoo.co.jp with HTTP; Thu, 12 Jan 2023 03:34:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1673494468; s=yj20110701; d=yahoo.co.jp; h=Message-ID:Date:MIME-Version:Subject:To:References:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=UHYXo92qkt1WlaPExvs5ikGgnDlBloQzkhOKdfIwo28=; b=Y2ICjhguDtIlgHWjVz/UIofJg2soACm5DNSjDt6Xh8VOSxsq74yEYRe9xDkr4njj yqaY7lpfNwBfNPj9dXyqqYZYxgN91cxAqjmlRGK2UWIa+/klTVLPRcfR5z9dBUFWtcl +qEu0zlOx51XcXIEGX6jF8hMy1f60NLSiGGwMebc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:Date:MIME-Version:References:Cc:From:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fx3chZov18IeE7y2naAriuiv/Ip4uWmdGG3xo89xIP+dgpHfFgW4ehcSPpVc0ssy ofMe88J8MZ7EK7Cy7wzyT6vpxa565DI5r3TVRkRZ0QIPrFbyONHOx5QOwmV94+QUJpp JgmQ44waxoA+EyZfTt+AayRhiJLzasYeRxiO2BGY=; Received: by smtphe5010.mail.kks.ynwp.yahoo.co.jp (YJ Hermes SMTP Server) with ESMTPA ID 4d16213910bf42964fa3e98dc8636282; Thu, 12 Jan 2023 12:34:27 +0900 (JST) Message-ID: <57ddc8f1-3099-d0aa-242d-3b1c9a8ff6ca@yahoo.co.jp> Date: Thu, 12 Jan 2023 12:34:25 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] ifcvt.cc: Prevent excessive if-conversion for conditional moves To: Robin Dapp References: <076a3744-f608-6f31-7244-2bf7ab06cdb1.ref@yahoo.co.jp> <076a3744-f608-6f31-7244-2bf7ab06cdb1@yahoo.co.jp> <38307fef-8b42-87ae-9900-d5ec1c1992fe@linux.ibm.com> Cc: GCC Patches From: Takayuki 'January June' Suwa In-Reply-To: <38307fef-8b42-87ae-9900-d5ec1c1992fe@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: On 2023/01/11 17:02, Robin Dapp wrote: > Hi, Hi! > >> On optimizing for speed, default_noce_conversion_profitable_p() allows >> plenty of headroom, so this patch has little impact. >> >> Also, if the target-specific cost estimate is accurate or allows for >> margins, the impact should be similarly small. > I believe this part of ifcvt does/did not use the costing on purpose. > It will generally convert more sequences than other paths that compare > before and after costs since we just count the number of converted > insns comparing them against the "branch costs". Similar to rtx costs > they are kind of relative to a single insn but AFAIK it's not used > consistently everywhere. All the major platforms have low branch costs > nowadays (0 or 1?) thus we won't emit too many conditional moves here. > > In general I agree that we should compare costs everywhere and not just > count (the costing should include the branch costs as well) but this would > be a major overhaul. For your case (assuming xtensa), could you not > tune xtensa_branch_cost? It is currently 3 allowing up to 4 conditional > moves to be generated. optimize_function_for_speed_p is already being > passed to the hook so you could make use of that and decrease branch > costs when optimizing for size only. > > Regards > Robin Thank you for your detailed explanation. In my case (for Xtensa), the cost of branching isn't really an issue. The actual problem (that I think) is the costs of the sequence itself before and after conversion. It is due to the fact that ifcvt's internal estimation is based on PATTERN(insn), so the instruction lengths ("length" attribute) associated with insns are not well reflected. This is especially noticeable when optimizing for size (overestimating the original cost). Currently, in addition to the patch, I have implemented the following code, and I'm confirming that it works roughly well (fine adjustments are still required). /* Return true if the instruction sequence seq is a good candidate as a replacement for the if-convertible sequence described in if_info. */ static bool xtensa_noce_conversion_profitable_p (rtx_insn *seq, struct noce_if_info *if_info) { unsigned int cost, original_cost; bool speed_p; rtx_insn *insn; speed_p = if_info->speed_p; /* of TEST_BB */ /* Estimate the cost for the replacing sequence. */ cost = 0; for (insn = seq; insn; insn = NEXT_INSN (insn)) if (active_insn_p (insn)) cost += xtensa_insn_cost (insn, speed_p); /* Short circuit and margins if optimiziing for speed. */ if (speed_p) return cost <= if_info->max_seq_cost; /* Estimate the cost for the original sequence if optimizing for size. */ original_cost = xtensa_insn_cost (if_info->jump, speed_p); speed_p = optimize_bb_for_speed_p (if_info->then_bb); FOR_BB_INSNS (if_info->then_bb, insn) if (active_insn_p (insn)) original_cost += xtensa_insn_cost (insn, speed_p); if (if_info->else_bb) { speed_p = optimize_bb_for_speed_p (if_info->else_bb); FOR_BB_INSNS (if_info->else_bb, insn) if (active_insn_p (insn)) original_cost += xtensa_insn_cost (insn, speed_p); } return cost <= original_cost; }