public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/54236] New: [SH] Improve addc and subc insn utilization
Date: Sun, 12 Aug 2012 22:25:00 -0000	[thread overview]
Message-ID: <bug-54236-4@http.gcc.gnu.org/bugzilla/> (raw)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236

             Bug #: 54236
           Summary: [SH] Improve addc and subc insn utilization
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: olegendo@gcc.gnu.org
        ReportedBy: olegendo@gcc.gnu.org
            Target: sh*-*-*


There are currently a couple of cases, where it would be better if addc or subc
insns were used.  For example:

int test00 (int a, int b)
{
  return a + b + 1;
}


gets compiled to:

        mov     r4,r0   ! MT
        add     r5,r0   ! EX
        rts
        add     #1,r0   ! EX

could be better as:

        mov     r4,r0   ! MT
        sett    r5,r0   ! MT (SH4)
        rts
        addc    #1,r0   ! EX

As a proof of concept, I've applied the following to handle the above case:

Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md    (revision 190326)
+++ gcc/config/sh/sh.md    (working copy)
@@ -1465,7 +1465,7 @@

 (define_insn "addc"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")
-    (plus:SI (plus:SI (match_operand:SI 1 "arith_reg_operand" "0")
+    (plus:SI (plus:SI (match_operand:SI 1 "arith_reg_operand" "%0")
               (match_operand:SI 2 "arith_reg_operand" "r"))
          (reg:SI T_REG)))
    (set (reg:SI T_REG)
@@ -1516,6 +1516,24 @@
   "add    %2,%0"
   [(set_attr "type" "arith")])

+(define_insn_and_split "*addsi3_compact"
+  [(set (match_operand:SI 0 "arith_reg_dest" "")
+    (plus:SI (plus:SI (match_operand:SI 1 "arith_reg_operand" "")
+               (match_operand:SI 2 "arith_reg_operand" ""))
+         (const_int 1)))
+   (clobber (reg:SI T_REG))]
+  "TARGET_SH1"
+  "#"
+  "&& 1"
+  [(set (reg:SI T_REG) (const_int 1))
+   (parallel [(set (match_dup 0)
+           (plus:SI (plus:SI (match_dup 1)
+                     (match_dup 2))
+                (reg:SI T_REG)))
+          (set (reg:SI T_REG)
+           (ltu:SI (plus:SI (match_dup 1) (match_dup 2))
+               (match_dup 1)))])])
+
 ;; -------------------------------------------------------------------------
 ;; Subtraction instructions
 ;; -------------------------------------------------------------------------

.. and observed some code from the CSiBE set for -O2 -m4-single -ml
-mpretend-cmove.  It doesn't affect code size that much (some incs/decs here
and there), but more importantly it does this (libmpeg2/motion_comp.c):

_MC_avg_o_16_c:            --> 
        mov.b   @r5,r1            mov.b    @r5,r2
.L16:                .L16:
        mov.b   @r4,r2                  sett
        extu.b  r1,r1                   mov.b    @r4,r1
        extu.b  r2,r2                   extu.b    r2,r2
        add     r2,r1                   extu.b    r1,r1
        add     #1,r1                   addc    r2,r1
        shar    r1                      shar    r1
        mov.b   r1,@r4                  mov.b    r1,@r4
        mov.b   @(1,r5),r0              sett
        extu.b  r0,r1                   mov.b    @(1,r5),r0
        mov.b   @(1,r4),r0              extu.b    r0,r1
        extu.b  r0,r0                   mov.b    @(1,r4),r0
        add     r0,r1                   extu.b    r0,r0
        add     #1,r1                   addc    r1,r0
        shar    r1                      shar    r0
        mov     r1,r0                   mov.b    r0,@(1,r4)
        mov.b   r0,@(1,r4)

In such cases, the sett,addc sequence can be scheduled much better and in most
cases the sett insn can be executed in parallel with some other insn.
Unfortunately, on SH4A the sett insn has been moved from MT group to EX group,
but still it seems beneficial.  I've also seen a couple of places, where
sett-subc sequences would be better.


             reply	other threads:[~2012-08-12 22:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-12 22:25 olegendo at gcc dot gnu.org [this message]
2012-08-12 22:35 ` [Bug target/54236] " olegendo at gcc dot gnu.org
2012-08-16 23:20 ` olegendo at gcc dot gnu.org
2012-09-19 17:46 ` olegendo at gcc dot gnu.org
2013-09-22 22:22 ` olegendo at gcc dot gnu.org
2013-10-29 20:46 ` olegendo at gcc dot gnu.org
2013-11-02 10:20 ` olegendo at gcc dot gnu.org
2013-11-03 17:50 ` olegendo at gcc dot gnu.org
2013-11-03 20:44 ` olegendo at gcc dot gnu.org
2014-05-21  8:06 ` olegendo at gcc dot gnu.org
2014-09-27 17:42 ` olegendo at gcc dot gnu.org
2015-01-24 13:05 ` olegendo at gcc dot gnu.org
2015-01-25 16:42 ` olegendo at gcc dot gnu.org
2015-05-17 21:02 ` olegendo at gcc dot gnu.org
2015-05-19  8:01 ` olegendo at gcc dot gnu.org
2015-05-21 12:37 ` olegendo at gcc dot gnu.org
2015-07-19  5:32 ` olegendo at gcc dot gnu.org
2015-07-19  6:47 ` olegendo at gcc dot gnu.org
2015-09-28 14:01 ` olegendo at gcc dot gnu.org

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=bug-54236-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).