[Bug target/57690] New: bextr sometimes used instead of shr

[Bug target/57690] New: bextr sometimes used instead of shr

[jakub at gcc dot gnu.org]

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

            Bug ID: 57690
           Summary: bextr sometimes used instead of shr
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org

unsigned int bar (void);
unsigned long foo (unsigned int x) { return bar () >> 2; }

With -O2 -mtbm we get:
   0:    48 83 ec 08              sub    $0x8,%rsp
   4:    e8 00 00 00 00           callq  9 <foo+0x9>
            5: R_X86_64_PC32    bar-0x4
   9:    48 83 c4 08              add    $0x8,%rsp
   d:    8f ea f8 10 c0 02 1e     bextr  $0x1e02,%rax,%rax
  14:    00 00 
  16:    c3                       retq   
while without it:
   0:    48 83 ec 08              sub    $0x8,%rsp
   4:    e8 00 00 00 00           callq  9 <foo+0x9>
            5: R_X86_64_PC32    bar-0x4
   9:    48 83 c4 08              add    $0x8,%rsp
   d:    c1 e8 02                 shr    $0x2,%eax
  10:    c3                       retq   
which is much shorter.  On the other side, bextr with immediate gives more
freedom to the register allocator, because it is a non-destructive source
instruction.  So, perhaps we want a peephole2 which will transform some forms
of the immediate TARGET_TBM tbm_bextr* (those where upper bits of a SImode or
DImode value are extracted and where destination is the same as source) into
shrl.
For -Os maybe it would be even shorter to emit movl + shrl.

[Bug target/57690] bextr sometimes used instead of shr

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-30
     Ever confirmed|0                           |1

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
For some reason combine simplifies

  (zero_extend:DI (lshiftrt:SI (reg:SI 0 ax [orig:65 D.1730 ] [65])
                        (const_int 2 [0x2]))))

to 

  (set (reg:DI 0 ax [orig:64 D.1733 ] [64])
       (zero_extract:DI (reg:DI 0 ax [orig:59 D.1732 ] [59])
                    (const_int 30 [0x1e])
                    (const_int 2 [0x2])))

perhaps correct RTX costs could prevent this transformation for -Os?
>From gcc-bugs-return-425466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 30 11:46:06 2013
Return-Path: <gcc-bugs-return-425466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30937 invoked by alias); 30 Jun 2013 11:46:06 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30887 invoked by uid 48); 30 Jun 2013 11:46:00 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/57760] preprocessor directive supress g++ warning
Date: Sun, 30 Jun 2013 11:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: RESOLVED
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: bug_status resolution
Message-ID: <bug-57760-4-nhEvRqIZTM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57760-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57760-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-06/txt/msg01845.txt.bz2
Content-length: 498

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW760

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Use -Wsystem-headers.  The directive marks the following contents as a system
header.

[Bug target/57690] bextr sometimes used instead of shr

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57690

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
6.1+ produces shr:
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        shrl    $2, %eax

combine dump for GCC 6.1:
Trying 8 -> 9:
Failed to match this instruction:
(set (reg:DI 91)
    (zero_extract:DI (reg:SI 87 [ _3 ])
        (const_int 30 [0x1e])
        (const_int 2 [0x2])))

Combine dump for 5.4:
Trying 8 -> 9:
Successfully matched this instruction:
(set (reg:DI 92 [ D.1847 ])
    (zero_extract:DI (subreg:DI (reg:SI 87 [ D.1846 ]) 0)
        (const_int 30 [0x1e])
        (const_int 2 [0x2])))
allowing combination of insns 8 and 9
original costs 4 + 1 = 5
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i3     9: {r92:DI=zero_extract(r87:SI#0,0x1e,0x2);clobber
flags:CC;}
      REG_UNUSED flags:CC
      REG_DEAD r87:SI
deferring rescan insn with uid = 9.
starting the processing of deferred insns
rescanning insn with uid = 9.
ending the processing of deferred insns

But I think GCC 6.1+ is producing invalid RTL in combine.  And it is no longer
matching the instruction.

I think the 6.1 behavior started with r6-2022.

[Bug target/57690] bextr sometimes used instead of shr

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57690

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed, this changed with r6-2022-gee40b04429bbf86e94579b11e29b7ece7b3c08a9
But certainly on this testcase it seems like a win.
I don't see anything invalid on the patterns combine creates.