From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omggw7008.mail.djm.yahoo.co.jp (omggw7008.mail.djm.yahoo.co.jp [183.79.54.43]) by sourceware.org (Postfix) with ESMTPS id A9C653858C5F for ; Thu, 1 Jun 2023 06:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9C653858C5F 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: UhSjrQ8VM1mE07xbJPhSEieJNj8nZwsHfdqrQTSB1YhWh6KsAld0idEbaZDwCLB T9iLnle1YVeAcUkN15_0wNZaohtdJ5Jsa.kRvdVzKJ8vLn9R9mUnp4CT4OK8A2bVJXEbRoXAJpy6 qhykvDcB5CDyzhK92zAXDzxkqqV4MYeBE49mjQKP5otGLS6s5Nez4G0PY7qbgcaOHYmJYCLKtW.y ZNM5I9yKH_iISgcYVuhD.VaRPpxbSbFFQErSf9Y76VJ5U4QOfire80enIiJDPPz6aSmD2QWId6uS UZlN6TDZyotbxHJbYqJqcC3vkwieYPBv5SIZq.RcRBAnElYjrbEb0XUEwHO7P1Vga0NmvhibuSG5 U7XT2LJcVvuhbbPGu27MWzlnicpJ.QhbQ6DP5dQRD9pq3nrKZ2orApczsfAT4YAPPpGh_bLnWZmY frzeQ7X3Ko.SwQ2rome8bDNFG2amEomDYLscKrjhTIHpd3YU9H6Wju58CwNsF0lF0zAMubpw39et WyOi7UOf0NBzFSnklmMv2ngh9MGMtpop9a54vgkdKK1mYqOqzpebTuQtKwsPmSNHZjnsH6OmVYIO OmIKDY6nZRouVqzXWstX_f7xoAtJXcgbLQ0H8XY6CHj8srRGigHhEmS7nUPifSDREIXc8IQlRpHa taKznxcNkI0be6tVZDPVCuBK9R7BdHs4HfSuHtzcTx1Wf1GlKMXGr.P30dI21I.SRGWPK0Nvpv.4 cQzy3aT2cwURRrpJxiWtSEsOfkmTAVX7gJNnLYoWUPMHyQ7WDYLnP7zxQhO1YvEIH3bO22H5KXvd OgpmDL6zhGrLGktrsxQNuiReFWdw5HVWRNmfx2LNHhifN8GdTF6KeqZMPmPig9MTYX1X1CIzhU8v EtoXRbXsXRorHHkYnbitAlvkWhH.mvcdXkusrfg5B.mKUHROAmyWRegQrUsPftdhWEAOZEbfpjLx j_3T0KDhz8DBZfMi4frZYOYPMHlcaQvApQqgVxx8XjqeltZwnEpKg04MdABAeMNS0t4E- Received: from sonicgw.mail.yahoo.co.jp by sonicconh5003.mail.kks.yahoo.co.jp with HTTP; Thu, 1 Jun 2023 06:01:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1685599275; s=yj20110701; d=yahoo.co.jp; h=Message-ID:Date:MIME-Version:Subject:To:References:From:Cc:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=JMwNvRemxft2ob/QuWT1fzucaNesy9HN9sV3iI14xAI=; b=iThM86DNWIqJrXwpN06NJt87tP7RN37gLN7IIOlQypWnrakvwDTilMTdO351+Q73 QupfAOT2A6nPvjH6pIhm1Ock/Spag8+rzbgTFIsn3WMRg0bKauAydBfpMwLVNGROyIh KbRwP+A++RkO+QvPWi60nle24u9VCBmn/v+NFJBs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:Date:MIME-Version:References:From:Cc:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=L/pmRhDLggr1g3ITOSEodK59GoQcMeIBSmTxfIi3sX+iliJGd98Zc14jSm9IXTTq 1dqZVhbxjBGJn5tn4V2XqD4eCykZVmQcUP4BVl87f+0iEUVY86l4Qvzyt21dsoiUdMk UrZj3uCEJmUFz4kQTxUhYtapGkQvRWak29ow5vmk=; Received: by smtphe5010.mail.kks.ynwp.yahoo.co.jp (YJ Hermes SMTP Server) with ESMTPA ID 9695469e93e789cc5988791bef961d0f; Thu, 01 Jun 2023 15:01:11 +0900 (JST) Message-ID: <931ab50b-8b5a-4979-b442-f193896a1a4f@yahoo.co.jp> Date: Thu, 1 Jun 2023 15:01:07 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: [PATCH 2/3 v3] xtensa: Add 'adddi3' and 'subdi3' insn patterns To: GCC Patches References: <95b8b130-caef-12c8-b247-25ec7dbf0ac3.ref@yahoo.co.jp> <95b8b130-caef-12c8-b247-25ec7dbf0ac3@yahoo.co.jp> From: Takayuki 'January June' Suwa Cc: Max Filippov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GIT_PATCH_0,KAM_DMARC_STATUS,NML_ADSP_CUSTOM_MED,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 List-Id: On 2023/05/31 15:02, Max Filippov wrote: Hi! > On Tue, May 30, 2023 at 2:50 AM Takayuki 'January June' Suwa > wrote: >> >> Resubmitting the correct one due to a mistake in merging order of fixes. >> --- >> More optimized than the default RTL generation. >> >> gcc/ChangeLog: >> >> * config/xtensa/xtensa.md (adddi3, subdi3): >> New RTL generation patterns implemented according to the instruc- >> tion idioms described in the Xtensa ISA reference manual (p. 600). >> --- >> gcc/config/xtensa/xtensa.md | 52 +++++++++++++++++++++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> >> diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md >> index eda1353894b..6882baaedfd 100644 >> --- a/gcc/config/xtensa/xtensa.md >> +++ b/gcc/config/xtensa/xtensa.md >> @@ -190,6 +190,32 @@ >> (set_attr "mode" "SI") >> (set_attr "length" "3")]) >> >> +(define_expand "adddi3" >> + [(set (match_operand:DI 0 "register_operand") >> + (plus:DI (match_operand:DI 1 "register_operand") >> + (match_operand:DI 2 "register_operand")))] >> + "" >> +{ >> + rtx lo_dest, hi_dest, lo_op0, hi_op0, lo_op1, hi_op1; >> + rtx_code_label *label; >> + lo_dest = gen_lowpart (SImode, operands[0]); >> + hi_dest = gen_highpart (SImode, operands[0]); >> + lo_op0 = gen_lowpart (SImode, operands[1]); >> + hi_op0 = gen_highpart (SImode, operands[1]); >> + lo_op1 = gen_lowpart (SImode, operands[2]); >> + hi_op1 = gen_highpart (SImode, operands[2]); >> + if (rtx_equal_p (lo_dest, lo_op1)) >> + FAIL; > > With this condition I see the following source > > unsigned long long foo(unsigned long long a, unsigned long long b) > { > return a + b; > } > > turns to (expected) > > .global foo > .type foo, @function > foo: > add.n a2, a2, a4 > add.n a3, a3, a5 > bgeu a2, a4, .L2 > addi.n a3, a3, 1 > .L2: > ret.n > > but > > unsigned long long foo(unsigned long long a, unsigned long long b) > { > return b + a; > } > > has an extra instruction: > > .global foo > .type foo, @function > foo: > mov.n a9, a2 > add.n a2, a4, a2 > add.n a3, a5, a3 > bgeu a2, a9, .L2 > addi.n a3, a3, 1 > .L2: > ret.n > > I though that maybe the following would help (plus using > lo_cmp in the emit_cmp_and_jump_insns below): > > if (!rtx_equal_p (lo_dest, lo_op0)) > lo_cmp = lo_op0; > else if (!rtx_equal_p (lo_dest, lo_op1)) > lo_cmp = lo_op1; > else > FAIL; > > but to my surprise it doesn't. As you may have noticed, at the time of RTL generation both of the above- mentioned are almost the same (only a and b have been swapped). Whether or not there are extra registers is determined at a later stage, so there is very little that can be done about it at (define_expand). I thought as above, but when I looked at the generated RTL again, I noticed that I could somehow make a decision based on the order of the generated pseudo-register numbers. > >> + emit_clobber (operands[0]); > > Why is this clobber needed? Apparently there is no need to clobber explicitly (because even if omitted, it will appear in the generated result). > >> + emit_insn (gen_addsi3 (lo_dest, lo_op0, lo_op1)); >> + emit_insn (gen_addsi3 (hi_dest, hi_op0, hi_op1)); >> + emit_cmp_and_jump_insns (lo_dest, lo_op1, GEU, const0_rtx, >> + SImode, true, label = gen_label_rtx ()); >> + emit_insn (gen_addsi3 (hi_dest, hi_dest, const1_rtx)); >> + emit_label (label); >> + DONE; >> +}) >> + >> (define_insn "addsf3" >> [(set (match_operand:SF 0 "register_operand" "=f") >> (plus:SF (match_operand:SF 1 "register_operand" "%f") >> @@ -237,6 +263,32 @@ >> (const_int 5) >> (const_int 6)))]) >> >> +(define_expand "subdi3" >> + [(set (match_operand:DI 0 "register_operand") >> + (minus:DI (match_operand:DI 1 "register_operand") >> + (match_operand:DI 2 "register_operand")))] >> + "" >> +{ >> + rtx lo_dest, hi_dest, lo_op0, hi_op0, lo_op1, hi_op1; >> + rtx_code_label *label; >> + lo_dest = gen_lowpart (SImode, operands[0]); >> + hi_dest = gen_highpart (SImode, operands[0]); >> + lo_op0 = gen_lowpart (SImode, operands[1]); >> + hi_op0 = gen_highpart (SImode, operands[1]); >> + lo_op1 = gen_lowpart (SImode, operands[2]); >> + hi_op1 = gen_highpart (SImode, operands[2]); >> + if (rtx_equal_p (lo_op0, lo_op1)) >> + FAIL; > > I believe that for the emit_cmp_and_jump_insns below > the check here should look like this: > > if (rtx_equal_p (lo_dest, lo_op0) || rtx_equal_p (lo_dest, lo_op1)) > > But maybe drop this check and use the following instead? > > emit_insn (gen_subsi3 (hi_dest, hi_op0, hi_op1)); > emit_cmp_and_jump_insns (lo_op0, lo_op1, GEU, const0_rtx, > SImode, true, label = gen_label_rtx ()); > emit_insn (gen_addsi3 (hi_dest, hi_dest, constm1_rtx)); > emit_label (label); > emit_insn (gen_subsi3 (lo_dest, lo_op0, lo_op1)); This seems like a better improvement. > >> + emit_clobber (operands[0]); > > Why is this clobber needed? > >> + emit_insn (gen_subsi3 (lo_dest, lo_op0, lo_op1)); >> + emit_insn (gen_subsi3 (hi_dest, hi_op0, hi_op1)); >> + emit_cmp_and_jump_insns (lo_op0, lo_op1, GEU, const0_rtx, >> + SImode, true, label = gen_label_rtx ()); >> + emit_insn (gen_addsi3 (hi_dest, hi_dest, constm1_rtx)); >> + emit_label (label); >> + DONE; >> +}) >> + >> (define_insn "subsf3" >> [(set (match_operand:SF 0 "register_operand" "=f") >> (minus:SF (match_operand:SF 1 "register_operand" "f") >> -- >> 2.30.2 > === More optimized than the default RTL generation. gcc/ChangeLog: * config/xtensa/xtensa.md (adddi3, subdi3): New RTL generation patterns implemented according to the instruc- tion idioms described in the Xtensa ISA reference manual (p. 600). --- gcc/config/xtensa/xtensa.md | 52 +++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md index eda1353894b..21afa747e89 100644 --- a/gcc/config/xtensa/xtensa.md +++ b/gcc/config/xtensa/xtensa.md @@ -190,6 +190,35 @@ (set_attr "mode" "SI") (set_attr "length" "3")]) +(define_expand "adddi3" + [(set (match_operand:DI 0 "register_operand") + (plus:DI (match_operand:DI 1 "register_operand") + (match_operand:DI 2 "register_operand")))] + "" +{ + rtx lo_dest, hi_dest, lo_op0, hi_op0, lo_op1, hi_op1; + rtx_code_label *label; + if (rtx_equal_p (operands[0], operands[1]) + || rtx_equal_p (operands[0], operands[2]) + || ! REG_P (operands[1]) || ! REG_P (operands[2])) + FAIL; + lo_dest = gen_lowpart (SImode, operands[0]); + hi_dest = gen_highpart (SImode, operands[0]); + lo_op0 = gen_lowpart (SImode, operands[1]); + hi_op0 = gen_highpart (SImode, operands[1]); + lo_op1 = gen_lowpart (SImode, operands[2]); + hi_op1 = gen_highpart (SImode, operands[2]); + emit_insn (gen_addsi3 (hi_dest, hi_op0, hi_op1)); + emit_insn (gen_addsi3 (lo_dest, lo_op0, lo_op1)); + emit_cmp_and_jump_insns (lo_dest, + (REGNO (operands[1]) < REGNO (operands[2]) + ? lo_op1 : lo_op0), GEU, const0_rtx, + SImode, true, label = gen_label_rtx ()); + emit_insn (gen_addsi3 (hi_dest, hi_dest, const1_rtx)); + emit_label (label); + DONE; +}) + (define_insn "addsf3" [(set (match_operand:SF 0 "register_operand" "=f") (plus:SF (match_operand:SF 1 "register_operand" "%f") @@ -237,6 +266,29 @@ (const_int 5) (const_int 6)))]) +(define_expand "subdi3" + [(set (match_operand:DI 0 "register_operand") + (minus:DI (match_operand:DI 1 "register_operand") + (match_operand:DI 2 "register_operand")))] + "" +{ + rtx lo_dest, hi_dest, lo_op0, hi_op0, lo_op1, hi_op1; + rtx_code_label *label; + lo_dest = gen_lowpart (SImode, operands[0]); + hi_dest = gen_highpart (SImode, operands[0]); + lo_op0 = gen_lowpart (SImode, operands[1]); + hi_op0 = gen_highpart (SImode, operands[1]); + lo_op1 = gen_lowpart (SImode, operands[2]); + hi_op1 = gen_highpart (SImode, operands[2]); + emit_insn (gen_subsi3 (hi_dest, hi_op0, hi_op1)); + emit_cmp_and_jump_insns (lo_op0, lo_op1, GEU, const0_rtx, + SImode, true, label = gen_label_rtx ()); + emit_insn (gen_addsi3 (hi_dest, hi_dest, constm1_rtx)); + emit_label (label); + emit_insn (gen_subsi3 (lo_dest, lo_op0, lo_op1)); + DONE; +}) + (define_insn "subsf3" [(set (match_operand:SF 0 "register_operand" "=f") (minus:SF (match_operand:SF 1 "register_operand" "f") -- 2.30.2