From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-432950-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4392 invoked by alias); 29 Oct 2013 21:58:09 -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 4342 invoked by uid 48); 29 Oct 2013 21:58:04 -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: Tue, 29 Oct 2013 21:58: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-URKfPvWC7l@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-10/txt/msg02094.txt.bz2

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

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
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.  So combine sees
the following:

(insn 11 6 12 2 (set (reg:QI 169 [ *a_3(D) ])
        (mem:QI (reg:SI 4 r4 [ a ]) [0 *a_3(D)+0 S1 A8])) {*movqi}
     (expr_list:REG_DEAD (reg:SI 4 r4 [ a ])
        (nil)))
(insn 12 11 13 2 (set (reg:SI 168 [ *a_3(D)+-3 ])
        (zero_extend:SI (reg:QI 169 [ *a_3(D) ]))) {*zero_extendqisi2_compact}
     (expr_list:REG_DEAD (reg:QI 169 [ *a_3(D) ])
        (nil)))
(insn 13 12 14 2 (set (reg:QI 171 [ *b_5(D) ])
        (mem:QI (reg:SI 5 r5 [ b ]) [0 *b_5(D)+0 S1 A8])) {*movqi}
     (expr_list:REG_DEAD (reg:SI 5 r5 [ b ])
        (nil)))
(insn 14 13 15 2 (set (reg:SI 170 [ *b_5(D)+-3 ])
        (zero_extend:SI (reg:QI 171 [ *b_5(D) ]))) {*zero_extendqisi2_compact}
     (expr_list:REG_DEAD (reg:QI 171 [ *b_5(D) ])
        (nil)))
(insn 15 14 16 2 (set (reg:SI 147 t)
        (eq:SI (reg:SI 168 [ *a_3(D)+-3 ])
            (reg:SI 170 [ *b_5(D)+-3 ]))) {cmpeqsi_t}
     (expr_list:REG_DEAD (reg:SI 170 [ *b_5(D)+-3 ])
        (expr_list:REG_DEAD (reg:SI 168 [ *a_3(D)+-3 ])
            (nil))))

On the other hand, signed char mem loads are expanded as sign extending.
Since LOAD_EXTEND_OP tells that any mem loads but SImode are sign extending,
one could expect that all mem loads will be automatically expanded as such,
which is not the case.