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/53987] [SH] Unnecessary zero-extension before cmp/eq
Date: Mon, 16 Dec 2013 19:07:00 -0000	[thread overview]
Message-ID: <bug-53987-4-WLJ5di24XD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-53987-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #2)
> As of rev 204180 (4.9) this problem still exists.
> As far as I understand, the actual root of the problem is that the 'unsigned
> char' mem loads into regs are neither sign nor zero extended.

I've tried doing the following to enforce sign extension of memory loads <
SImode:

Index: gcc/config/sh/sh.md
===================================================================
--- gcc/config/sh/sh.md    (revision 205971)
+++ gcc/config/sh/sh.md    (working copy)
@@ -5958,7 +5958,18 @@

 (define_expand "zero_extend<mode>si2"
   [(set (match_operand:SI 0 "arith_reg_dest")
-    (zero_extend:SI (match_operand:QIHI 1 "zero_extend_operand")))])
+    (zero_extend:SI (match_operand:QIHI 1 "general_extend_operand")))]
+  ""
+{
+  if (!zero_extend_operand (operands[1], <MODE>mode))
+    {
+      rtx tmp = gen_reg_rtx (SImode);
+      emit_insn (gen_extend<mode>si2 (tmp, operands[1]));
+      emit_insn (gen_zero_extend<mode>si2 (operands[0],
+                       gen_lowpart (<MODE>mode, tmp)));
+      DONE;
+    }
+})

 (define_insn_and_split "*zero_extend<mode>si2_compact"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")

However, this doesn't fix the problem.
According to CSiBE (-m4 -ml -O2 -mpretend-cmove) there are a few cases where
register allocation is a bit better, but there are also some code size
increases (e.g. interference with the tst #imm,r0 patterns).  There's a code
size decrease of 228 bytes on the whole set.

Nevertheless, having the explicit sign_extend mem loads could be useful.  For
example knowing that a mem load sign extends the cmpeq insn could be hoisted
above the extension insns before register allocation.
On SH2A it's probably better to not allow zero extending mem loads in the
expander and defer the movu.{b|w} insn selection until the combine pass. 
Otherwise the original test case will always use zero extending mem loads, even
though sign extending ones would suffice (16 bit insns vs 32 bit insns).


  parent reply	other threads:[~2013-12-16 19:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16 23:50 [Bug target/53987] New: " olegendo at gcc dot gnu.org
2012-08-31 18:14 ` [Bug target/53987] " olegendo at gcc dot gnu.org
2013-10-29 21:58 ` olegendo at gcc dot gnu.org
2013-12-16 19:07 ` olegendo at gcc dot gnu.org [this message]
2014-12-17 21:09 ` olegendo at gcc dot gnu.org
2014-12-21 16:54 ` [Bug target/53987] [SH] Unnecessary zero-extensions olegendo at gcc dot gnu.org
2014-12-22 22:27 ` olegendo at gcc dot gnu.org
2014-12-25  1:11 ` olegendo at gcc dot gnu.org
2014-12-30 17:26 ` olegendo at gcc dot gnu.org
2015-01-15  1:37 ` olegendo at gcc dot gnu.org
2015-01-24 13:06 ` olegendo at gcc dot gnu.org
2015-01-27 23:08 ` olegendo at gcc dot gnu.org
2015-08-01  9:57 ` olegendo at gcc dot gnu.org
2015-09-09 12:15 ` 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-53987-4-WLJ5di24XD@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).