public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Takayuki 'January June' Suwa <jjsuwa_sys3175@yahoo.co.jp>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Subject: [PATCH 2/3 v3] xtensa: Add 'adddi3' and 'subdi3' insn patterns
Date: Thu, 1 Jun 2023 15:01:07 +0900	[thread overview]
Message-ID: <931ab50b-8b5a-4979-b442-f193896a1a4f@yahoo.co.jp> (raw)
In-Reply-To: <CAMo8BfJg2k=yRCiPe9DmzfNkb5sMPwKCQzxikfcqn8CfsUBuRw@mail.gmail.com>

On 2023/05/31 15:02, Max Filippov wrote:
Hi!

> On Tue, May 30, 2023 at 2:50 AM Takayuki 'January June' Suwa
> <jjsuwa_sys3175@yahoo.co.jp> 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

  reply	other threads:[~2023-06-01  6:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <95b8b130-caef-12c8-b247-25ec7dbf0ac3.ref@yahoo.co.jp>
2023-05-30  9:50 ` [PATCH 2/3 v2] " Takayuki 'January June' Suwa
2023-05-31  6:02   ` Max Filippov
2023-06-01  6:01     ` Takayuki 'January June' Suwa [this message]
2023-06-01 14:16       ` [PATCH 2/3 v3] " Max Filippov
2023-06-01 14:20       ` Max Filippov
2023-06-01 15:36         ` Takayuki 'January June' Suwa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=931ab50b-8b5a-4979-b442-f193896a1a4f@yahoo.co.jp \
    --to=jjsuwa_sys3175@yahoo.co.jp \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jcmvbkbc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).