[Bug target/59968] New: Unused BT patterns

[Bug target/59968] New: Unused BT patterns

[hjl.tools at gmail dot com]

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

            Bug ID: 59968
           Summary: Unused BT patterns
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
            Target: x86/x86-64

There are some BT patterns in i386 guarded with
TARGET_USE_BT.  But there are no testcases to show
if they are used at all.

Also BT instructions supports memory destination.
But BT patterns only allow register destination.

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-28
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int
__attribute__((noinline))
foo1 (int x, int y)
{
  x |= 1 << y;
  return x;
}

we generate

    movl    %esi, %ecx
    movl    $1, %eax
    sall    %cl, %eax
    orl    %edi, %eax
    ret

I am expecting

    movl    %edi, %eax
    bts     %esi, %eax
    ret

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |areg.melikadamyan at gmail dot com
                   |                            |, kirill.yukhin at intel dot com

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
  bar1 |= 1 << y;
}

we generate:

    movl    $1, %eax
    movl    %edi, %ecx
    sall    %cl, %eax
    orl    %eax, bar1(%rip)
    ret

I am expecting:

    bts     %edi, bar1(%rip)
    ret

[Bug target/59968] Unused BT patterns

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #0)
> There are some BT patterns in i386 guarded with
> TARGET_USE_BT.  But there are no testcases to show
> if they are used at all.

testsuite/gcc.target/i386/bt-*.c

> Also BT instructions supports memory destination.
> But BT patterns only allow register destination.

bt with a memory operand is slow. The bitpos argument is not limited to operand
size, and is primarily used for locked memory access.

BTW:

$ objdump -d cc1 | grep "bt " | wc -l
1228
>From gcc-bugs-return-441765-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 28 16:23:25 2014
Return-Path: <gcc-bugs-return-441765-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10293 invoked by alias); 28 Jan 2014 16:23:25 -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 10246 invoked by uid 55); 28 Jan 2014 16:23:21 -0000
From: "hjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59672] Add -m16 support for x86
Date: Tue, 28 Jan 2014 16:23: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: hjl 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59672-4-Tec5uzMOuQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59672-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59672-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: 2014-01/txt/msg02907.txt.bz2
Content-length: 2117

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

--- Comment #8 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Tue Jan 28 16:22:45 2014
New Revision: 207196

URL: http://gcc.gnu.org/viewcvs?rev 7196&root=gcc&view=rev
Log:
Add -m16 support for x86

The .code16gcc directive was added to binutils back in 1999:

---
   '.code16gcc' provides experimental support for generating 16-bit code
from gcc, and differs from '.code16' in that 'call', 'ret', 'enter',
'leave', 'push', 'pop', 'pusha', 'popa', 'pushf', and 'popf'
instructions default to 32-bit size.  This is so that the stack pointer
is manipulated in the same way over function calls, allowing access to
function parameters at the same stack offsets as in 32-bit mode.
'.code16gcc' also automatically adds address size prefixes where
necessary to use the 32-bit addressing modes that gcc generates.
---

It encodes 32-bit assembly instructions generated by GCC in 16-bit format
so that GCC can be used to generate 16-bit instructions.  To do that, the
.code16gcc directive must be placed at the very beginning of the assembly
code.  This patch adds -m16 to x86 backend by:

1. Add -m16 and make it mutually exclusive with -m32, -m64 and -mx32.
2. Treat -m16 like -m32 so that --32 is passed to assembler.
3. Output .code16gcc at the very beginning of the assembly code.
4. Turn off 64-bit ISA when -m16 is used.

    PR target/59672
    * config/i386/gnu-user64.h (SPEC_32): Add "m16|" to "m32".
    (SPEC_X32): Likewise.
    (SPEC_64): Likewise.
    * config/i386/i386.c (ix86_option_override_internal): Turn off
    OPTION_MASK_ISA_64BIT, OPTION_MASK_ABI_X32 and OPTION_MASK_ABI_64
    for TARGET_16BIT.
    (x86_file_start): Output .code16gcc for TARGET_16BIT.
    * config/i386/i386.h (TARGET_16BIT): New macro.
    (TARGET_16BIT_P): Likewise.
    * config/i386/i386.opt: Add m16.
    * doc/invoke.texi: Document -m16.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/gnu-user64.h
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/i386.h
    trunk/gcc/config/i386/i386.opt
    trunk/gcc/doc/invoke.texi

[Bug target/59968] Unused BT patterns

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 11778 bytes --]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
The conversion to bt is somewhat fragile ATM, implemented with various
splitters. 

There was discussion to represent bit-test instructions with its own RTX, with
the intention to generate them from middle-end in a more consistent way.
>From gcc-bugs-return-441767-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 28 16:28:39 2014
Return-Path: <gcc-bugs-return-441767-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17605 invoked by alias); 28 Jan 2014 16:28:39 -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 17583 invoked by uid 48); 28 Jan 2014 16:28:35 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59261] [4.9 regression] FAIL: gcc.dg/vect/bb-slp-26.c -flto -ffat-lto-objects (internal compiler error)
Date: Tue, 28 Jan 2014 16:28: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-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59261-4-EBKWnalviP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59261-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59261-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg02909.txt.bz2
Content-length: 7578

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

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
$ gcc/xgcc -B gcc/ ../gcc/testsuite/gcc.dg/vect/bb-slp-26.c -flto
-ffat-lto-objects -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -v
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --build=ia64-suse-linux
--host=ia64-suse-linux --enable-checking=release --enable-shared
--with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g'
Thread model: posix
gcc version 4.9.0 20140128 (experimental) [trunk revision 207160] (GCC) 
COLLECT_GCC_OPTIONS='-B' 'gcc/' '-flto' '-ffat-lto-objects' '-ftree-vectorize'
'-fvect-cost-model=unlimited' '-fno-common' '-O2' '-v'
 gcc/cc1 -quiet -v -iprefix
/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/ia64-suse-linux/4.9.0/
-isystem gcc/include -isystem gcc/include-fixed
../gcc/testsuite/gcc.dg/vect/bb-slp-26.c -quiet -dumpbase bb-slp-26.c -auxbase
bb-slp-26 -O2 -version -flto -ffat-lto-objects -ftree-vectorize
-fvect-cost-model=unlimited -fno-common -o /tmp/ccnI2B5p.s
GNU C (GCC) version 4.9.0 20140128 (experimental) [trunk revision 207160]
(ia64-suse-linux)
        compiled by GNU C version 4.9.0 20140128 (experimental) [trunk revision
207160], GMP version 4.3.2, MPFR version 2.4.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/ia64-suse-linux/4.9.0/include"
ignoring nonexistent directory
"/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/ia64-suse-linux/4.9.0/include-fixed"
ignoring nonexistent directory
"/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/ia64-suse-linux/4.9.0/../../../../ia64-suse-linux/include"
ignoring nonexistent directory
"/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/../../lib/gcc/ia64-suse-linux/4.9.0/include"
ignoring nonexistent directory
"/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/../../lib/gcc/ia64-suse-linux/4.9.0/include-fixed"
ignoring nonexistent directory
"/usr/local/gcc/gcc-20140128/Build/gcc/../lib/gcc/../../lib/gcc/ia64-suse-linux/4.9.0/../../../../ia64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 gcc/include
 gcc/include-fixed
 /usr/local/include
 /usr/include
End of search list.
GNU C (GCC) version 4.9.0 20140128 (experimental) [trunk revision 207160]
(ia64-suse-linux)
        compiled by GNU C version 4.9.0 20140128 (experimental) [trunk revision
207160], GMP version 4.3.2, MPFR version 2.4.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9ec120f50573ca1e0b5055cf7d3946d0
COLLECT_GCC_OPTIONS='-B' 'gcc/' '-flto' '-ffat-lto-objects' '-ftree-vectorize'
'-fvect-cost-model=unlimited' '-fno-common' '-O2' '-v'
 gcc/as -v -x -o /tmp/ccIBjE6p.o /tmp/ccnI2B5p.s
GNU assembler version 2.23.1 (ia64-suse-linux) using BFD version (GNU Binutils;
SUSE Linux Enterprise 11) 2.23.1
COMPILER_PATH=gcc/
LIBRARY_PATH=gcc/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' 'gcc/' '-flto' '-ffat-lto-objects' '-ftree-vectorize'
'-fvect-cost-model=unlimited' '-fno-common' '-O2' '-v'
 gcc/collect2 -plugin gcc/liblto_plugin.so -plugin-opt=gcc/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccAVXv8p.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lunwind
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lunwind -flto
-dynamic-linker /lib/ld-linux-ia64.so.2 /usr/lib/crt1.o /usr/lib/crti.o
gcc/crtbegin.o -Lgcc /tmp/ccIBjE6p.o -lgcc --as-needed -lgcc_s -lunwind
--no-as-needed -lc -lgcc --as-needed -lgcc_s -lunwind --no-as-needed
gcc/crtend.o /usr/lib/crtn.o
 gcc/xgcc @/tmp/cc8GnggF.args
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --build=ia64-suse-linux
--host=ia64-suse-linux --enable-checking=release --enable-shared
--with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g'
Thread model: posix
gcc version 4.9.0 20140128 (experimental) [trunk revision 207160] (GCC) 
COLLECT_GCC_OPTIONS='-c' '-B' 'gcc/' '-ffat-lto-objects' '-ftree-vectorize'
'-fvect-cost-model=unlimited' '-fno-common' '-O2' '-v'
'-fltrans-output-list=/tmp/cceMmjdF.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccAVXv8p.res'
 gcc/lto1 -quiet -dumpbase ccIBjE6p.o -auxbase ccIBjE6p -O2 -version
-ffat-lto-objects -ftree-vectorize -fvect-cost-model=unlimited -fno-common
-fltrans-output-list=/tmp/cceMmjdF.ltrans.out -fwpa
-fresolution=/tmp/ccAVXv8p.res @/tmp/ccDZYbNE
GNU GIMPLE (GCC) version 4.9.0 20140128 (experimental) [trunk revision 207160]
(ia64-suse-linux)
        compiled by GNU C version 4.9.0 20140128 (experimental) [trunk revision
207160], GMP version 4.3.2, MPFR version 2.4.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU GIMPLE (GCC) version 4.9.0 20140128 (experimental) [trunk revision 207160]
(ia64-suse-linux)
        compiled by GNU C version 4.9.0 20140128 (experimental) [trunk revision
207160], GMP version 4.3.2, MPFR version 2.4.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COMPILER_PATH=gcc/:gcc/
LIBRARY_PATH=gcc/:gcc/:/lib/:/usr/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-B' 'gcc/' '-ffat-lto-objects' '-ftree-vectorize'
'-fvect-cost-model=unlimited' '-fno-common' '-O2' '-v'
'-fltrans-output-list=/tmp/cceMmjdF.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccAVXv8p.res'
 gcc/xgcc @/tmp/ccOQeYmF.args
Reading specs from gcc/specs
COLLECT_GCC=gcc/xgcc
Target: ia64-suse-linux
Configured with: ../configure --prefix=/usr --build=ia64-suse-linux
--host=ia64-suse-linux --enable-checking=release --enable-shared
--with-system-zlib CFLAGS='-O2 -g' CXXFLAGS='-O2 -g'
Thread model: posix
gcc version 4.9.0 20140128 (experimental) [trunk revision 207160] (GCC) 
COLLECT_GCC_OPTIONS='-c' '-B' 'gcc/' '-ffat-lto-objects' '-ftree-vectorize'
'-fvect-cost-model=unlimited' '-fno-common' '-O2' '-v'
'-fltrans-output-list=/tmp/cceMmjdF.ltrans.out' '-fltrans' '-o'
'/tmp/cceMmjdF.ltrans0.ltrans.o'
 gcc/lto1 -quiet -dumpbase cceMmjdF.ltrans0.o -auxbase-strip
/tmp/cceMmjdF.ltrans0.ltrans.o -O2 -version -ffat-lto-objects -ftree-vectorize
-fvect-cost-model=unlimited -fno-common
-fltrans-output-list=/tmp/cceMmjdF.ltrans.out -fltrans @/tmp/ccxXeTwH -o
/tmp/cc7D4GAH.s
GNU GIMPLE (GCC) version 4.9.0 20140128 (experimental) [trunk revision 207160]
(ia64-suse-linux)
        compiled by GNU C version 4.9.0 20140128 (experimental) [trunk revision
207160], GMP version 4.3.2, MPFR version 2.4.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU GIMPLE (GCC) version 4.9.0 20140128 (experimental) [trunk revision 207160]
(ia64-suse-linux)
        compiled by GNU C version 4.9.0 20140128 (experimental) [trunk revision
207160], GMP version 4.3.2, MPFR version 2.4.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
../gcc/testsuite/gcc.dg/vect/bb-slp-26.c: In function ‘main’:
../gcc/testsuite/gcc.dg/vect/bb-slp-26.c:19:14: internal compiler error: in
expand_shift_1, at expmed.c:2315
       dst[0] += A*src[0] + src[stride];
>From gcc-bugs-return-441768-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 28 16:31:32 2014
Return-Path: <gcc-bugs-return-441768-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22011 invoked by alias); 28 Jan 2014 16:31:31 -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 21995 invoked by uid 48); 28 Jan 2014 16:31:28 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59261] [4.9 regression] FAIL: gcc.dg/vect/bb-slp-26.c -flto -ffat-lto-objects (internal compiler error)
Date: Tue, 28 Jan 2014 16:31: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-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-59261-4-tfWLXMxNcJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59261-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59261-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: 2014-01/txt/msg02910.txt.bz2
Content-length: 246

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

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
Created attachment 31969
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id1969&actioníit
Intermediate files from -save-temps

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int
__attribute__((noinline))
foo1 (int x, int y)
{
  x &= ~(1 << y);
  return x;
}

we generate

    movl    %esi, %ecx
    movl    $-2, %eax
    roll    %cl, %eax
    andl    %edi, %eax
    ret

I expect

    movl    %edi, %eax
    btr     %esi, %eax
    ret

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
  if (!(bar1 & (1 << y)))
    bar1 |= 1 << y;
}

we generate

    movl    bar1(%rip), %eax
    btl    %edi, %eax
    jc    .L1
    movl    $1, %edx
    movl    %edi, %ecx
    sall    %cl, %edx
    orl    %edx, %eax
    movl    %eax, bar1(%rip)
.L1:
    rep ret

I expect:

    bts     %edi, bar2(%rip)
    ret

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
  if (!(bar1 & (1 << y)))
    {
      bar1 |= 1 << y;
      xxx1 ();
    }
}

we generate

    .cfi_startproc
    movl    bar1(%rip), %eax
    btl    %edi, %eax
    jnc    .L5
    rep ret
    .p2align 4,,10
    .p2align 3
.L5:
    movl    $1, %edx
    movl    %edi, %ecx
    sall    %cl, %edx
    orl    %edx, %eax
    movl    %eax, bar1(%rip)
    jmp    xxx1

I expect

    bts %edi, bar2(%rip)
    jc .L7
    jmp    xxx2
.L8:
    .p2align 4,,10
    .p2align 3
.L7:
    rep ret

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
  if ((bar1 & (1 << y)))
    {
      bar1 &= ~(1 << y);
      xxx1 ();
    }
}

we generate

    movl    bar1(%rip), %eax
    btl    %edi, %eax
    jc    .L5
    rep ret
    .p2align 4,,10
    .p2align 3
.L5:
    movl    $-2, %edx
    movl    %edi, %ecx
    roll    %cl, %edx
    andl    %edx, %eax
    movl    %eax, bar1(%rip)
    jmp    xxx1

I expect
    btr %edi, bar2(%rip)
    jnc .L7
    jmp    xxx2
.L8:
    .p2align 4,,10
    .p2align 3
.L7:
    rep ret

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
For

int bar1;
void
__attribute__((noinline))
foo1 (int y)
{
  if ((bar1 & (1 << y)))
    bar1 &= ~(1 << y);
}

we generate

    .cfi_startproc
    movl    bar1(%rip), %eax
    btl    %edi, %eax
    jnc    .L1
    movl    $-2, %edx
    movl    %edi, %ecx
    roll    %cl, %edx
    andl    %edx, %eax
    movl    %eax, bar1(%rip)
.L1:
    rep ret

I expect

    btr %edi, bar2(%rip)
    ret

[Bug target/59968] Unused BT patterns

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to H.J. Lu from comment #8)
> 
> I expect:
> 
> 	bts     %edi, bar2(%rip)

Did you see Comment #3?
>From gcc-bugs-return-441790-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 28 18:46:41 2014
Return-Path: <gcc-bugs-return-441790-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23540 invoked by alias); 28 Jan 2014 18:46:41 -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 23281 invoked by uid 48); 28 Jan 2014 18:46:37 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58701] [4.9 Regression] [c++11] ICE initializing member of static union
Date: Tue, 28 Jan 2014 18:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-58701-4-WvjmR3wItb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58701-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58701-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: 2014-01/txt/msg02932.txt.bz2
Content-length: 374

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org

[Bug target/59968] Unused BT patterns

[ubizjak at gmail dot com]

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

--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
From i386.md:

;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation.  When applied to registers,
;; it depends on the cpu implementation.  They're never faster than
;; the corresponding and/ior/xor operations, so with 32-bit there's
;; no point.  But in 64-bit, we can't hold the relevant immediates
;; within the instruction itself, so operating on bits in the high
;; 32-bits of a register becomes easier.
;;
;; These are slow on Nocona, but fast on Athlon64.  We do require the use
;; of btrq and btcq for corner cases of post-reload expansion of absdf and
;; negdf respectively, so they can never be disabled entirely.
>From gcc-bugs-return-441792-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 28 18:48:53 2014
Return-Path: <gcc-bugs-return-441792-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28019 invoked by alias); 28 Jan 2014 18:48:53 -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 27926 invoked by uid 48); 28 Jan 2014 18:48:49 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59916] [4.9 Regression] constructors and destructors can cause "control reaches end of non-void function" warnings with -Os
Date: Tue, 28 Jan 2014 18:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason 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: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59916-4-RQ0rIQP5jg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59916-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59916-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: 2014-01/txt/msg02934.txt.bz2
Content-length: 529

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
>   <retval> = B::B (this, 0, __vtt_parm);

That assigns to the RESULT_DECL, which should count as a return.

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #14)
> From i386.md:
> 
> ;; %%% bts, btr, btc, bt.
> ;; In general these instructions are *slow* when applied to memory,
> ;; since they enforce atomic operation.  When applied to registers,
> ;; it depends on the cpu implementation.  They're never faster than
> ;; the corresponding and/ior/xor operations, so with 32-bit there's
> ;; no point.  But in 64-bit, we can't hold the relevant immediates
> ;; within the instruction itself, so operating on bits in the high
> ;; 32-bits of a register becomes easier.
> ;;

BTx with memory operand are slow, but they have smaller code
sizes.  We can optimize well for register operand as the first
step.
>From gcc-bugs-return-441812-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 28 22:29:36 2014
Return-Path: <gcc-bugs-return-441812-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29423 invoked by alias); 28 Jan 2014 22:29:35 -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 29400 invoked by uid 48); 28 Jan 2014 22:29:31 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types
Date: Tue, 28 Jan 2014 22:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.7.4
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: janus at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59941-4-NKXTF5OHvD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59941-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59941-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: 2014-01/txt/msg02954.txt.bz2
Content-length: 232

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

--- Comment #13 from janus at gcc dot gnu.org ---
(In reply to janus from comment #12)
> Here is a more lightweight fix (pretty much straightforward):

... and regtesting cleanly.

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
I couldn't get GCC to use those BT patterns:

(define_insn "*btsq"
  [(set (zero_extract:DI (match_operand:DI 0 "register_operand" "+r")
                         (const_int 1)
                         (match_operand:DI 1 "const_0_to_63_operand"))
        (const_int 1))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_64BIT && (TARGET_USE_BT || reload_completed)"
  "bts{q}\t{%1, %0|%0, %1}"
  [(set_attr "type" "alu1")
   (set_attr "prefix_0f" "1")
   (set_attr "mode" "DI")])

(define_insn "*btrq"
  [(set (zero_extract:DI (match_operand:DI 0 "register_operand" "+r")
                         (const_int 1)
                         (match_operand:DI 1 "const_0_to_63_operand"))
        (const_int 0))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_64BIT && (TARGET_USE_BT || reload_completed)"
  "btr{q}\t{%1, %0|%0, %1}"
  [(set_attr "type" "alu1")
   (set_attr "prefix_0f" "1")
   (set_attr "mode" "DI")])

(define_insn "*btcq"
  [(set (zero_extract:DI (match_operand:DI 0 "register_operand" "+r")
                         (const_int 1)
                         (match_operand:DI 1 "const_0_to_63_operand"))
        (not:DI (zero_extract:DI (match_dup 0) (const_int 1) (match_dup 1))))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_64BIT && (TARGET_USE_BT || reload_completed)"
  "btc{q}\t{%1, %0|%0, %1}"
  [(set_attr "type" "alu1")
   (set_attr "prefix_0f" "1")
   (set_attr "mode" "DI")])

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 31974
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31974&action=edit
A micro-benchmark for BTS with register

BTS with register operand is about 7-20% faster on Silvermont
an Haswell.

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31974|0                           |1
        is obsolete|                            |

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 31983
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31983&action=edit
Micro-benchmark for bt, btr, bts

These micro-benchmark for bt, btr, bts show
that BTx with register operand is 8 to 30%
faster on Sandy Bride, Ivy Bridge, Haswell
and Silvermont.

[Bug target/59968] Unused BT patterns

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
For

---
int
foo1 (int x, int y)
{
  x &= 1 << y;
  return x != 0;
}
---

combine fails to try

(set (reg:CCZ 17 flags)
    (compare:CCZ (and:SI (lshiftrt:SI (reg/v:SI 88 [ x ])
                (subreg:QI (reg/v:SI 89 [ y ]) 0)) 
            (const_int 1 [0x1]))
        (const_int 0 [0])))
(set (reg:SI 94 [ D.1754 ])
    (ne:SI (reg:CCZ 17 flags)
        (const_int 0 [0])))

which can be turned into

(set (reg:CCC 17 flags)
    (compare:CCC (and:SI (lshiftrt:SI (reg/v:SI 88 [ x ])
                (subreg:QI (reg/v:SI 89 [ y ]) 0)) 
            (const_int 1 [0x1]))
        (const_int 0 [0])))
(set (reg:SI 94 [ D.1754 ])
    (ne:SI (reg:CCC 17 flags)
        (const_int 0 [0])))

[Bug target/59968] Unused BT patterns

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think most of these have been fixed.  For an example comment #19 was fixed in
r12-1525