[Bug target/59021] New: [4.9 regression] new vzeroupper instructions generated with -mavx

[Bug target/59021] New: [4.9 regression] new vzeroupper instructions generated with -mavx

[ebotcazou at gcc dot gnu.org]

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

            Bug ID: 59021
           Summary: [4.9 regression] new vzeroupper instructions generated
                    with -mavx
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ebotcazou at gcc dot gnu.org

Created attachment 31173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31173&action=edit
Testcase

It's not clear to me whether this is a real bug or not, but new vzeroupper
instructions started to be generated with -mavx very recently because of:

2013-11-04  Vladimir Makarov  <vmakarov@redhat.com>

    PR rtl-optimization/58968
    * lra-spills.c (return_regno_p): New function.
    (lra_final_code_change): Use it.

For the attached testcase compiled with -O2 -mavx:

--- t.s.0       2013-11-06 12:17:49.080691443 +0100
+++ t.s 2013-11-06 12:17:55.005691730 +0100
@@ -23,12 +23,14 @@
        call    foo
        testl   %eax, %eax
        jne     .L6
+       vzeroupper
        leave
        .cfi_remember_state
        .cfi_def_cfa 7, 8
        ret
 .L6:
        .cfi_restore_state
+       vzeroupper
        call    abort
        .cfi_endproc
 .LFE0:

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*, i?86-*-*
   Target Milestone|---                         |4.9.0

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

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

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Kirill, can please someone from your team comment on the testcase?
>From gcc-bugs-return-433725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 06 14:07:07 2013
Return-Path: <gcc-bugs-return-433725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2679 invoked by alias); 6 Nov 2013 14:07:07 -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 1910 invoked by uid 48); 6 Nov 2013 14:05:05 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/58580] [4.8 Regression] preprocessor goes OOM with warning for zero literals
Date: Wed, 06 Nov 2013 14:07: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.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: dodji at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_known_to_work resolution short_desc cf_known_to_fail
Message-ID: <bug-58580-4-WmtcL012E4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58580-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58580-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-11/txt/msg00502.txt.bz2
Content-length: 791

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
      Known to work|                            |4.9.0
         Resolution|FIXED                       |---
            Summary|[4.8/4.9 Regression]        |[4.8 Regression]
                   |preprocessor goes OOM with  |preprocessor goes OOM with
                   |warning for zero literals   |warning for zero literals
      Known to fail|                            |4.8.2

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah.  Re-opening, fixed on trunk only sofar.

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
Isn't the argument list a bit strange for call insn?

(call_insn 20 19 21 2 (set (reg:SI 0 ax)
        (call (mem:QI (symbol_ref:DI ("foo") [flags 0x41]  <function_decl
0x2b9e82c58f00 foo>) [0 foo S1 A8])
            (const_int 16 [0x10]))) pr59021.c:15 660 {*call_value}
     (nil)
    (expr_list:V4DF (use (reg:V4DF 21 xmm0))
        (expr_list:REG_BR_PRED (use (reg:SI 5 di))
            (expr_list:REG_BR_PRED (use (reg:SI 4 si))
                (expr_list:REG_BR_PRED (use (reg:SI 1 dx))
                    (expr_list:REG_BR_PRED (use (reg:SI 2 cx))
                        (expr_list:REG_BR_PRED (use (reg:SI 37 r8))
                            (expr_list:REG_DEAD (use (mem:BLK (reg/f:DI 7 sp)
[0 S12 A64]))
                                (nil)))))))))


These should be (expr_list:REG_DEP_TRUE (use (...))
>From gcc-bugs-return-433730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 06 14:43:43 2013
Return-Path: <gcc-bugs-return-433730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15571 invoked by alias); 6 Nov 2013 14:43:43 -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 12608 invoked by uid 48); 6 Nov 2013 14:41:41 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/58697] [4.8/4.9 Regression] wrong code (segfaults) at -O3
Date: Wed, 06 Nov 2013 14:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-58697-4-gvgJNcyzoz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58697-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58697-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-11/txt/msg00507.txt.bz2
Content-length: 498

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

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

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's a dup.

*** This bug has been marked as a duplicate of bug 58653 ***

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-11-06
           Assignee|unassigned at gcc dot gnu.org      |ubizjak at gmail dot com
     Ever confirmed|0                           |1

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
I have patch in testing.

--cut here--
Index: config/i386/i386.c
===================================================================
--- config/i386/i386.c  (revision 204459)
+++ config/i386/i386.c  (working copy)
@@ -15708,7 +15708,7 @@ ix86_avx_u128_mode_needed (rtx insn)
              rtx arg = XEXP (XEXP (link, 0), 0);

              if (ix86_check_avx256_register (&arg, NULL))
-               return AVX_U128_ANY;
+               return AVX_U128_DIRTY;
            }
        }

--cut here--
>From gcc-bugs-return-433744-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 06 17:43:40 2013
Return-Path: <gcc-bugs-return-433744-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30532 invoked by alias); 6 Nov 2013 17:43:40 -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 29018 invoked by uid 48); 6 Nov 2013 17:41:38 -0000
From: "kcc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32
Date: Wed, 06 Nov 2013 17:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kcc 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.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59018-4-lnXFahagCe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59018-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59018-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-11/txt/msg00521.txt.bz2
Content-length: 1041

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

--- Comment #1 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
At least one of these patches does not build with clang:

/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:807:21:
error: ignored asm label 'r8' on automatic variable [-Werror]
  void *r8 __asm__ ("r8") = newtls;
                    ^
/home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:808:21:
error: ignored asm label 'r10' on automatic variable [-Werror]
  int *r10 __asm__ ("r10") = child_tidptr;
                    ^

is this some kind of gcc-specific syntax?
(forgive my ignorance here)

Two general questions:

1. Before doing the merge I test the patch like this:
rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'

What should I add to this line to also test x32?

2. Is there any chance to test x32 off the clang tree, so that we keep the
upstream tree x32-clean all the time?

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #3)
> I have patch in testing.

The call_insn RTX should always define its mode. Previously, the state was
switched to DIRTY by an eventual move to a 256bit function argument register
(even when the move was useless) in front of the call_insn. Nowadays, this is
not true anymore, so call_insn should switch the state to DIRTY mode on its
own.
>From gcc-bugs-return-433747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 06 17:55:27 2013
Return-Path: <gcc-bugs-return-433747-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8519 invoked by alias); 6 Nov 2013 17:55:27 -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 6944 invoked by uid 48); 6 Nov 2013 17:53:25 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59018] [4.9 Regression] libsanitizer doesn't build for x32
Date: Wed, 06 Nov 2013 17:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools 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.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59018-4-yBCBWpET5l@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59018-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59018-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-11/txt/msg00524.txt.bz2
Content-length: 1574

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Kostya Serebryany from comment #1)
> At least one of these patches does not build with clang:
>
> /home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
> 807:21: error: ignored asm label 'r8' on automatic variable [-Werror]
>   void *r8 __asm__ ("r8") = newtls;
>                     ^
> /home/kcc/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:
> 808:21: error: ignored asm label 'r10' on automatic variable [-Werror]
>   int *r10 __asm__ ("r10") = child_tidptr;
>                     ^
>
> is this some kind of gcc-specific syntax?
> (forgive my ignorance here)

Can you try

  register void *r8 __asm__ ("r8") = newtls;
  register int *r10 __asm__ ("r10") = child_tidptr;

as suggested by Jakub?

> Two general questions:
>
> 1. Before doing the merge I test the patch like this:
> rm -rf */{*/,}libsanitizer && make -j 50  && make -C gcc check-g{cc,++}
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
>
> What should I add to this line to also test x32?

I am using:

RUNTESTFLAGS='--target_board=unix\{-mx32,-m32,-m64\} asan.exp'

But you need to enable x32 first on your OS, which requires

1. x32 enabled kernel, Linux kernel >= 3.4.0.
2. x32 glibc.

>
> 2. Is there any chance to test x32 off the clang tree, so that we keep the
> upstream tree x32-clean all the time?

There was x32 port of llvm/clang last year.  But only parts
of the x32 patches have been merged with llvm.

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov  6 19:37:12 2013
New Revision: 204464

URL: http://gcc.gnu.org/viewcvs?rev=204464&root=gcc&view=rev
Log:
    PR target/59021
    * config/i386/i386.c (ix86_avx_u128_mode_needed): Require
    AVX_U128_DIRTY mode for call_insn RTXes that use AVX256 registers.
    (ix86_avx_u128_mode_needed): Return AVX_U128_DIRTY mode for call_insn
    RTXes that return in AVX256 register.

testsuite/ChangeLog:

    PR target/59021
    * gcc.target/i386/pr59021.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr59021.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/59021] [4.9 regression] new vzeroupper instructions generated with -mavx

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Nov 14 21:26:09 2013
New Revision: 204823

URL: http://gcc.gnu.org/viewcvs?rev=204823&root=gcc&view=rev
Log:
    Backport from mainline
    2013-11-10  Uros Bizjak  <ubizjak@gmail.com>

    * mode-switching.c (optimize_mode_switching): Mark block as
    nontransparent, if last_mode at block exit is different from no_mode.

    Backport from mainline
    2013-11-06  Uros Bizjak  <ubizjak@gmail.com>

    PR target/59021
    * config/i386/i386.c (ix86_avx_u128_mode_needed): Require
    AVX_U128_DIRTY mode for call_insn RTXes that use AVX256 registers.
    (ix86_avx_u128_mode_needed): Return AVX_U128_DIRTY mode for call_insn
    RTXes that return in AVX256 register.

testsuite/ChangeLog:

    Backport from mainline
    2013-11-11  Uros Bizjak  <ubizjak@gmail.com>

    PR target/58853
    * gcc.target/i386/pr58853.c: New test.


Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59021.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/mode-switching.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog