From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-393947-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14318 invoked by alias); 11 Jun 2012 09:47:32 -0000
Received: (qmail 14306 invoked by uid 22791); 11 Jun 2012 09:47:31 -0000
X-SWARE-Spam-Status: No, hits=-4.3 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 09:47:16 +0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/53623] [4.7/4.8 Regression] sign extension is effectively split into two x86-64 instructions
Date: Mon, 11 Jun 2012 09:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.2
X-Bugzilla-Changed-Fields: Depends on Target Milestone
Message-ID: <bug-53623-4-1u9xKbdzn8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53623-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53623-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
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
X-SW-Source: 2012-06/txt/msg00574.txt.bz2

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |50176
   Target Milestone|---                         |4.7.2

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-11 09:47:15 UTC ---
Forwprop does

--- t.c.024t.ccp1       2012-06-11 11:32:13.791164397 +0200
+++ t.c.025t.forwprop1  2012-06-11 11:32:13.792164397 +0200
@@ -11,7 +11,7 @@
 <bb 2>:
   D.1751_2 = code[rdx_1(D)];
   rdx_3 = (int64_t) D.1751_2;
-  inst_4 = (uint8_t) rdx_3;
+  inst_4 = (uint8_t) D.1751_2;
   rdx_5 = rdx_3 >> 8;
   D.1752_6 = (int) inst_4;
   D.1753_7 = dispatch[D.1752_6];

making D.1751_2 no longer single-use and thus no longer triggering combine.

Indeed looks related to 50176.

But while we certainly can teach forwprop to only consider single-use
chains (to never possibly cause this issue) it isn't a good solution.
In fact for properly optimizing this we need to know whether cheap
sub-reg like accesses are possible (combining (int) (uint8_t) (int64_t)
code[rdx_1] to simply extending the lower part of (int64_t) code[rdx_1]
without explicit truncation).  This seems more fit for an RTL optimization
pass than for a tree pass if consider the forwprop "optimization" be done
in source like

#include <stdint.h>

typedef (*inst_t)(int64_t rdi, int64_t rsi, int64_t rdx);

int16_t code[256];
inst_t dispatch[256];

void an_inst(int64_t rdi, int64_t rsi, int64_t rdx) {
    uint8_t inst;
    inst = (uint8_t) code[rdx];
    rdx = code[rdx];
    rdx >>= 8;
    dispatch[inst](rdi, rsi, rdx);
}

int main(void) {
    return 0;
}

which you could easily get from some level of abstraction.