From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-437764-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 32613 invoked by alias); 16 Dec 2013 19:07:51 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 32583 invoked by uid 48); 16 Dec 2013 19:07:48 -0000
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
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-53987-4-WLJ5di24XD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53987-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53987-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01419.txt.bz2

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).