[Bug rtl-optimization/62011] New: False Data Dependency in popcnt instruction

[Bug rtl-optimization/62011] New: False Data Dependency in popcnt instruction

[debiandev at gmail dot com]

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

            Bug ID: 62011
           Summary: False Data Dependency in popcnt instruction
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: debiandev at gmail dot com

On Sandy/Ivy Bridge and Haswell processors, the instruction:

popcnt src, dest

appears to have a false dependency on the destination register dest. Even
though the instruction only writes to it, the instruction will wait until dest
is ready before executing.

This causes a loss in performance as explained here:
http://stackoverflow.com/questions/25078285/replacing-a-32-bit-loop-count-variable-with-64-bit-introduces-crazy-performance

[Bug target/62011] False Data Dependency in popcnt instruction

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Target|X86_64-*-*                  |x86_64-*-*, i?86-*-*

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please clarify - this is a defect in the CPU?  Can you point to an official
errata?

In which case we might want to adjust the scheduler description used for
GENERIC tuning (and for the specific broken CPUs).  Not sure if we want to
disable popcnt use completely.

[Bug target/62011] False Data Dependency in popcnt instruction

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

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

--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
I think adjusting for scheduling won't help much: rather than making the
compiler aware of increased latency, you'd need that either the register
allocator avoids using a recently written hard register for popcnt (I'm not
aware of such capability), or as a stopgap measure the compiler can issue a
dependency-breaking instruction (xor %reg %reg) just before popcnt.

[Bug target/62011] False Data Dependency in popcnt instruction

[debiandev at gmail dot com]

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

--- Comment #3 from Andev <debiandev at gmail dot com> ---
This seems to be specific to some latest Intel CPUs. I am not sure which other
CPUs are affected. There is no official errata for this behavior AFAIK. 

As Alexander suggested, it would be a great idea to have a work around for this
in gcc for these specific CPUs.

[Bug target/62011] False Data Dependency in popcnt instruction

[finis at in dot tum.de]

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

--- Comment #5 from finis at in dot tum.de ---
Maybe there are a lot more instructions with such a false dependency. popcnt
may only be the tip of the ice berg. I don't think Intel only got this
operation wrong and all other SSE/AVX/... instructions are correct. I rather
think a group of operations is implemented like popcnt. The source code in the
linked SO question yields a good testbed for other operations as well: Simply
replace popcount by another intrinsic and check if the performance deviations
occur.

[Bug target/62011] False Data Dependency in popcnt instruction

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev <ysrumyan at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ysrumyan at gmail dot com

--- Comment #6 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
I don't see any issues with 'false dependency' on HSW. I've got sep data on it:

for unsigned veriant (with LEA instructions):

0x400b30 52 161 lea    0x1(%rdx),%ecx 
0x400b33 53 0 popcnt (%rbx,%rax,8),%rax 
0x400b39 54 353 lea    0x2(%rdx),%r8d 
0x400b3d 55 0 popcnt (%rbx,%rcx,8),%rcx 
0x400b43 56 170 add    %rax,%rcx 
0x400b46 57 25 lea    0x3(%rdx),%esi 
0x400b49 58 332 popcnt (%rbx,%r8,8),%rax 
0x400b4f 59 196 add    %rax,%rcx 
0x400b52 60 199 popcnt (%rbx,%rsi,8),%rax 
0x400b58 61 235 add    %rax,%rcx 
0x400b5b 62 414 lea    0x4(%rdx),%eax 
0x400b5e 63 0 add    %rcx,%r14 
0x400b61 64 312 mov    %rax,%rdx 
0x400b64 65 0 cmp    %rax,%r12 
0x400b67 66 0 ja     400b30 <main+0xb0> 

and we don't see any performance anomaly with popcnt.

But for 2nd loop we have

0x400c50 118 0 popcnt -0x8(%rdx),%rax 
0x400c56 119 0 popcnt (%rdx),%rcx 
0x400c5b 120 1086 add    %rax,%rcx 
0x400c5e 121 492 popcnt 0x8(%rdx),%rax 
0x400c64 122 3 add    %rcx,%rax 
0x400c67 123 507 add    $0x20,%rdx 
0x400c6b 124 0 popcnt -0x10(%rdx),%rcx 
0x400c71 125 955 add    %rax,%rcx 
0x400c74 126 479 add    %rcx,%r13 
0x400c77 127 489 cmp    %rsi,%rdx 
0x400c7a 128 0 jne    400c50 <main+0x1d0>

So far I can't imagine what the problem is.

[Bug target/62011] False Data Dependency in popcnt instruction

[ysrumyan at gmail dot com]

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

--- Comment #7 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
Please ignore my previous comment - if we insert nullifying of destination
register before each popcnt (and lzcnt) performance will restore:

original test results:

unsigned        83886630000     0.848533 sec    24.715 GB/s
uint64_t        83886630000     1.37436 sec     15.2592 GB/s

fixed popcnt:

unsigned        90440370000     0.853753 sec    24.5639 GB/s
uint64_t        83886630000     0.694458 sec    30.1984 GB/s

Here is assembly for 2nd loop:

.L16:
    xorq    %rax, %rax    
    popcntq    -8(%rdx), %rax
    xorq    %rcx, %rcx    
    popcntq    (%rdx), %rcx
    addq    %rax, %rcx
    xorq    %rax, %rax    
    popcntq    8(%rdx), %rax
    addq    %rcx, %rax
    addq    $32, %rdx
    xorq    %rcx, %rcx    
    popcntq    -16(%rdx), %rcx
    addq    %rax, %rcx
    addq    %rcx, %r13
    cmpq    %rsi, %rdx
    jne    .L16

[Bug target/62011] False Data Dependency in popcnt instruction

[finis at in dot tum.de]

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

--- Comment #8 from finis at in dot tum.de ---
@Yuri: Note however, that the result of your fixed u32 version seems to be
wrong.

[Bug target/62011] False Data Dependency in popcnt instruction

[ysrumyan at gmail dot com]

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

--- Comment #9 from Yuri Rumyantsev <ysrumyan at gmail dot com> ---
This is not u32 version but u64. The first loop (u32) version looks like:

.L23:
    leal    1(%rdx), %ecx
    xorq    %rax, %rax    
    popcntq    (%rbx,%rax,8), %rax
    leal    2(%rdx), %r8d
    xorq    %rcx, %rcx    
    popcntq    (%rbx,%rcx,8), %rcx
    addq    %rax, %rcx
    leal    3(%rdx), %esi
    xorq    %rax, %rax    
    popcntq    (%rbx,%r8,8), %rax
    addq    %rax, %rcx
    xorq    %rax, %rax    
    popcntq    (%rbx,%rsi,8), %rax
    addq    %rax, %rcx
    leal    4(%rdx), %eax
    addq    %rcx, %r14
    movq    %rax, %rdx
    cmpq    %rax, %r12
    ja    .L23

[Bug target/62011] False Data Dependency in popcnt instruction

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-13
     Ever confirmed|0                           |1

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed at least.

[Bug target/62011] False Data Dependency in popcnt instruction

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Aug 21 18:03:49 2014
New Revision: 214279

URL: https://gcc.gnu.org/viewcvs?rev=214279&root=gcc&view=rev
Log:
    Backport from mainline
    2014-08-19  H.J. Lu  <hongjiu.lu@intel.com>

    * config/i386/i386.md (*ctz<mode>2_falsedep_1): Don't clear
    destination if it is used in source.
    (*clz<mode>2_lzcnt_falsedep_1): Likewise.
    (*popcount<mode>2_falsedep_1): Likewise.

    Backport from mainline
    2014-08-18  Uros Bizjak  <ubizjak@gmail.com>

    PR target/62011
    * config/i386/x86-tune.def (X86_TUNE_AVOID_FALSE_DEP_FOR_BMI):
    New tune flag.
    * config/i386/i386.h (TARGET_AVOID_FALSE_DEP_FOR_BMI): New define.
    * config/i386/i386.md (unspec) <UNSPEC_INSN_FALSE_DEP>: New unspec.
    (ffs<mode>2): Do not expand with tzcnt for
    TARGET_AVOID_FALSE_DEP_FOR_BMI.
    (ffssi2_no_cmove): Ditto.
    (*tzcnt<mode>_1): Disable for TARGET_AVOID_FALSE_DEP_FOR_BMI.
    (ctz<mode>2): New expander.
    (*ctz<mode>2_falsedep_1): New insn_and_split pattern.
    (*ctz<mode>2_falsedep): New insn.
    (*ctz<mode>2): Rename from ctz<mode>2.
    (clz<mode>2_lzcnt): New expander.
    (*clz<mode>2_lzcnt_falsedep_1): New insn_and_split pattern.
    (*clz<mode>2_lzcnt_falsedep): New insn.
    (*clz<mode>2): Rename from ctz<mode>2.
    (popcount<mode>2): New expander.
    (*popcount<mode>2_falsedep_1): New insn_and_split pattern.
    (*popcount<mode>2_falsedep): New insn.
    (*popcount<mode>2): Rename from ctz<mode>2.
    (*popcount<mode>2_cmp): Remove.
    (*popcountsi2_cmp_zext): Ditto.


Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.h
    branches/gcc-4_9-branch/gcc/config/i386/i386.md
    branches/gcc-4_9-branch/gcc/config/i386/x86-tune.def

[Bug target/62011] False Data Dependency in popcnt instruction

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Uroš Bizjak <ubizjak at gmail dot com> ---
.
>From gcc-bugs-return-458986-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 21 18:06:35 2014
Return-Path: <gcc-bugs-return-458986-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22834 invoked by alias); 21 Aug 2014 18:06: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 22800 invoked by uid 48); 21 Aug 2014 18:06:32 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62011] False Data Dependency in popcnt instruction
Date: Thu, 21 Aug 2014 18:06: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: unknown
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: target_milestone
Message-ID: <bug-62011-4-xIURh5XN33@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62011-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62011-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-08/txt/msg01483.txt.bz2
Content-length: 383

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.2

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed for 4.9.2+.
>From gcc-bugs-return-458988-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 21 18:32:27 2014
Return-Path: <gcc-bugs-return-458988-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5540 invoked by alias); 21 Aug 2014 18:32:26 -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 5491 invoked by uid 48); 21 Aug 2014 18:32:22 -0000
From: "eric.niebler at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62219] New: [c++11] Spurious error for lambda in a friend function of a class template with a default template parameters
Date: Thu, 21 Aug 2014 18:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
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: eric.niebler at gmail dot com
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-62219-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-08/txt/msg01485.txt.bz2
Content-length: 988

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

            Bug ID: 62219
           Summary: [c++11] Spurious error for lambda in a friend function
                    of a class template with a default template parameters
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric.niebler at gmail dot com

This code:

    template< class = void >
    struct S
    {
      friend void foo( S )
      {
        [](){};
      }
    };

Gives me:

    test.cpp: In function ‘void foo(S< <template-parameter-1-1> >)’:
    test.cpp:6:8: error: default argument for template parameter for class
enclosing ‘foo(S< <template-parameter-1-1> >)::<lambda>’
         [](){};
            ^

I'm not sure what the error is trying to tell me. FWIW, the code compiles
cleanly with clang.
>From gcc-bugs-return-458989-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 21 18:53:34 2014
Return-Path: <gcc-bugs-return-458989-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27430 invoked by alias); 21 Aug 2014 18:53:33 -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 27405 invoked by uid 55); 21 Aug 2014 18:53:30 -0000
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/62214] [4.8/4.9/5 Regression] Problem with spread plus concatenation for characters
Date: Thu, 21 Aug 2014 18:53: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.8.2
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tkoenig at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: tkoenig at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62214-4-wD88GUp7KQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62214-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62214-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-08/txt/msg01486.txt.bz2
Content-length: 773

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb214

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Author: tkoenig
Date: Thu Aug 21 18:52:58 2014
New Revision: 214281

URL: https://gcc.gnu.org/viewcvs?rev!4281&root=gcc&view=rev
Log:
2014-08-21  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/62214
    * frontend-passes.c (optimize_binop_array_assignment):
    Do not try to optimize the array assignment for string
    concatenation.

2014-08-21  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/62214
    * gfortran.dg/array_assignment_5.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/array_assignment_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/frontend-passes.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/62011] False Data Dependency in popcnt instruction

[malincns at 163 dot com]

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

Ma Lin <malincns at 163 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |malincns at 163 dot com

--- Comment #18 from Ma Lin <malincns at 163 dot com> ---
FYI, in Intel 10th/11th Generation Processor Errata Table, there is no popcnt
problem.

In 9th Generation Errata Table, this problem exists.