[Bug rtl-optimization/64477] New: x86 sse unnecessary GPR spill

[Bug rtl-optimization/64477] New: x86 sse unnecessary GPR spill

[zoltan at hidvegi dot com]

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

            Bug ID: 64477
           Summary: x86 sse unnecessary GPR spill
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zoltan at hidvegi dot com

typedef signed char v16si __attribute__ ((vector_size (16)));
v16si ary(signed char a)
{
    return v16si{a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a};
}

Compiled with g++-4.9 -m64 -O2 -fomit-frame-pointer -Wall -I$HOME/dev/common
-mssse3 -std=gnu++11 -S xmm_test.C

I get

        pxor    %xmm1, %xmm1
        movd    %edi, %xmm0
        movl    %edi, -12(%rsp)
        pshufb  %xmm1, %xmm0
        ret

Note the unnecessary spill of edi, with gcc-4.8 this does not happen, so you
may consider this a regression. I think this may happen because it first tries
to move from gpr to xmm via the stack, but later optimizes to a direct gpr to
xmm move, but the stack spill stays.

When using -march=corei7-avx and 4x4 int vector, gcc-4.9 uses store to stack
and vbroadcastss instead of movd and pshufd  $0, %xmm1, %xmm0 used by gcc-4.8,
again gcc-4.8 seems better to me. But even gcc-4.8 goes through the stack in
that case with -mtune=generic

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization, ra
           Priority|P3                          |P2

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We end up with

(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 4 2 (set (mem/c:SI (plus:DI (reg/f:DI 7 sp)
                (const_int -12 [0xfffffffffffffff4])) [1 %sfp+-4 S4 A32])
        (reg:SI 5 di [ a ])) t.c:3 90 {*movsi_internal}
     (nil))
(note 4 2 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 4 9 2 (set (reg:V4SI 21 xmm0 [95])
        (vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 7 sp)
                        (const_int -12 [0xfffffffffffffff4])) [1 %sfp+-4 S4
A32]))
            (const_vector:V4SI [
                    (const_int 0 [0])
                    (const_int 0 [0])
                    (const_int 0 [0])
                    (const_int 0 [0])
                ])
            (const_int 1 [0x1]))) t.c:4 2460 {vec_setv4si_0}
     (nil))

after reload as it seems vec_setv4si_0 doesn't allow a di reg operand?

         Choosing alt 2 in insn 8:  (0) v  (1) C  (2) m {vec_setv4si_0}
            0 Non-pseudo reload: reject+=2
            0 Non input pseudo reload: reject++
          alt=0,overall=609,losers=1,rld_nregs=1
          alt=1,overall=0,losers=0,rld_nregs=0
         Choosing alt 1 in insn 2:  (0) m  (1) re {*movsi_internal}
           Spilling non-eliminable hard regs: 7

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I investigated this problem too.  IRA in GCC-4.9 allocates memory to the pseudo
in insn 2, then the memory slot is reloaded for insn 8.  Post-reload
optimization changes stack slot by register.

GCC-4.8 IRA allocates a register to the pseudo.  So the behaviour difference
starts in IRA.

I believe that DSE after RA should remove the store.  But the DSE optimization
algorithm is too simple.  It does not work for example with stack-pointer
addressed memory (only with frame-pointer addressed memory).  And x86-64 uses a
 stack-based addresses for stack slots by default.  Even if DSE were able to
work with stack-based addresses, I guess it also can not handle stack slot
sharing (it means we need CFG-sensitive global DSE).

This particular problem could be solved in IRA or in DSE.  I'll try to
investigate what can I do to fix it in IRA.  Still I belive we need much better
RTL-level DSE (dealing with stack-addressed memory slots, global and
CFG-sensitive DSE).

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Uros, your thoughts on this?

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #5)
> Uros, your thoughts on this?

All these *r are (were?) necessary for TARGET_INTER_UNIT_MOVES_{TO,FROM}_VEC to
avoid allocating general reg, but to go through memory.

It looks that this particular case is just an oversight, and this alternative
should be defined as (Yi/r/C), as is the case for similar sse2_loadd insn

Otherwise, these constraints were carefully fine-tuned for reload. IRA is
slightly different, and no wonder that these constraints will have to be
re-tuned in coming years.
>From gcc-bugs-return-474284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 21 21:52:29 2015
Return-Path: <gcc-bugs-return-474284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9968 invoked by alias); 21 Jan 2015 21:52:28 -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 9886 invoked by uid 55); 21 Jan 2015 21:52:20 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/62078] [5 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
Date: Wed, 21 Jan 2015 21:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-checking, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62078-4-gR2SNjFgxB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62078-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62078-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: 2015-01/txt/msg02278.txt.bz2
Content-length: 648

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Jan 21 21:51:43 2015
New Revision: 219970

URL: https://gcc.gnu.org/viewcvs?rev!9970&root=gcc&view=rev
Log:
    PR rtl-optimization/62078
    * dse.c: Include cfgcleanup.h.
    (rest_of_handle_dse): For -fnon-call-exceptions, if DSE removed
    anything call purge_all_dead_edges and cleanup_cfg at the end
    of the pass.

    * g++.dg/opt/pr62078.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/opt/pr62078.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dse.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|missed-optimization, ra     |
             Target|x86_64-*-*                  |x86
           Assignee|vmakarov at redhat dot com         |ubizjak at gmail dot com

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
Patch in testing:

--cut here--
Index: config/i386/sse.md
===================================================================
--- config/i386/sse.md  (revision 219987)
+++ config/i386/sse.md  (working copy)
@@ -6391,11 +6391,11 @@
 ;; see comment above inline_secondary_memory_needed function in i386.c
 (define_insn "vec_set<mode>_0"
   [(set (match_operand:VI4F_128 0 "nonimmediate_operand"
-         "=Yr,*v,v,v ,x,x,v,Yr ,*x ,x  ,m ,m   ,m")
+         "=Yr,*v,v,Yi,x,x,v,Yr ,*x ,x  ,m ,m   ,m")
        (vec_merge:VI4F_128
          (vec_duplicate:VI4F_128
            (match_operand:<ssescalarmode> 2 "general_operand"
-         " Yr,*v,m,*r,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF"))
+         " Yr,*v,m,r ,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF"))
          (match_operand:VI4F_128 1 "vector_move_operand"
          " C , C,C,C ,C,0,v,0  ,0  ,x  ,0 ,0   ,0")
          (const_int 1)))]
--cut here--
>From gcc-bugs-return-474325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 22 07:33:45 2015
Return-Path: <gcc-bugs-return-474325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4243 invoked by alias); 22 Jan 2015 07:33: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 4099 invoked by uid 48); 22 Jan 2015 07:33:31 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
Date: Thu, 22 Jan 2015 07:33: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.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: jakub 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60570-4-IRy0GnA9Xx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60570-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60570-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: 2015-01/txt/msg02319.txt.bz2
Content-length: 772

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`570

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So shall we then partially revert r136209 aka PR36320?
I say partially, because I think at least the addition of is_if argument to
_cpp_parse_expr should be preserved.

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[ubizjak at gmail dot com]

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
>From gcc-bugs-return-474334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 22 08:15:37 2015
Return-Path: <gcc-bugs-return-474334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3853 invoked by alias); 22 Jan 2015 08:15: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 3726 invoked by uid 48); 22 Jan 2015 08:15:17 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
Date: Thu, 22 Jan 2015 08:15: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64580-4-67HnxK7u5T@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64580-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64580-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: 2015-01/txt/msg02328.txt.bz2
Content-length: 4251

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

--- Comment #6 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Annotating rs6000_stack_info() in perf shows:

       │        /* First, find out if we use _any_ altivec registers.  */
       │        for (i = FIRST_ALTIVEC_REGNO; i <= LAST_ALTIVEC_REGNO; ++i)
       │          if (df_regs_ever_live_p (i))
  0.00 │        mr     r3,r31
       │        bl     10293df0 <.df_regs_ever_live_p(unsigned int)>
  0.00 │        nop
       │        cmpdi  cr7,r3,0
       │        beq    cr7,10a7c3f4 <.rs6000_stack_info()+0xc14>
       │            mask |= ALTIVEC_REG_BIT (i);
       │        addi   r9,r31,-77
       │        srw    r9,r22,r9
       │        or     r9,r9,r24
       │        clrldi r24,r9,32
       │        if (DEFAULT_ABI == ABI_DARWIN && crtl->calls_eh_return
       │            && ! TARGET_ALTIVEC)
       │          mask |= 0xFFF;
       │
       │        /* First, find out if we use _any_ altivec registers.  */
       │        for (i = FIRST_ALTIVEC_REGNO; i <= LAST_ALTIVEC_REGNO; ++i)
  0.00 │        addi   r31,r31,1
       │        cmplwi cr7,r31,109
       │        clrldi r31,r31,32
       │        bne    cr7,10a7c3d0 <.rs6000_stack_info()+0xbf0>
       │          if (df_regs_ever_live_p (i))
       │            mask |= ALTIVEC_REG_BIT (i);
       │
       │        if (mask == 0)
  0.00 │        cmpdi  cr7,r24,0
       │        beq    cr7,10a7c5c0 <.rs6000_stack_info()+0xde0>
       │        /* Next, remove the argument registers from the set.  These
must
       │           be in the VRSAVE mask set by the caller, so we don't need to
add
       │           them in again.  More importantly, the mask we compute here
is
       │           used to generate CLOBBERs in the set_vrsave insn, and we do
not
       │           wish the argument registers to die.  */
       │        for (i = crtl->args.info.vregno - 1; i >= ALTIVEC_ARG_MIN_REG;
--i)
       │        lwa    r10,144(r29)
       │        addi   r9,r10,-1
       │        cmplwi cr7,r9,78
       │        ble    cr7,10a7c458 <.rs6000_stack_info()+0xc78>
       │        addi   r10,r10,-78
       │          mask &= ~ALTIVEC_REG_BIT (i);
       │        lis    r8,-32768
       │        clrldi r10,r10,32
       │        addi   r9,r10,-2
       │        clrldi r9,r9,32
       │        addi   r9,r9,1
       │        mtctr  r9
       │        nop
       │        nop
 99.57 │        srw    r9,r8,r10
       │        addi   r10,r10,-1
       │        andc   r9,r24,r9
  0.41 │        clrldi r10,r10,32
       │        clrldi r24,r9,32
       │        /* Next, remove the argument registers from the set.  These
must
       │           be in the VRSAVE mask set by the caller, so we don't need to
add
       │           them in again.  More importantly, the mask we compute here
is
       │           used to generate CLOBBERs in the set_vrsave insn, and we do
not
       │           wish the argument registers to die.  */
       │        for (i = crtl->args.info.vregno - 1; i >= ALTIVEC_ARG_MIN_REG;
--i)
       │        bdnz   10a7c440 <.rs6000_stack_info()+0xc60>
       │          mask &= ~ALTIVEC_REG_BIT (i);
       │
       │        /* Similarly, remove the return value from the set.  */
       │        {
       │          bool yes = false;
       │        li     r9,0
       │        mr     r4,r1
       │          diddle_return_value (is_altivec_return_reg, &yes);
       │        addis  r3,r2,-4
       │        for (i = crtl->args.info.vregno - 1; i >= ALTIVEC_ARG_MIN_REG;
--i)
       │          mask &= ~ALTIVEC_REG_BIT (i);
>From gcc-bugs-return-474335-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 22 08:18:46 2015
Return-Path: <gcc-bugs-return-474335-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5783 invoked by alias); 22 Jan 2015 08:18:44 -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 5681 invoked by uid 48); 22 Jan 2015 08:18:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
Date: Thu, 22 Jan 2015 08:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: compile-time-hog, memory-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-64511-4-wHlfXrYjC3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64511-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64511-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: 2015-01/txt/msg02329.txt.bz2
Content-length: 292

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4527&actioníit
gcc5-ice-nobt.patch

Untested fix for the undesirable backtrace from driver.

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 22 14:43:55 2015
New Revision: 220000

URL: https://gcc.gnu.org/viewcvs?rev=220000&root=gcc&view=rev
Log:
    PR target/64688
    PR target/64477
    * config/i386/sse.md (vec_set<mode>_0): Use (Yi/r/C) constraints
    for alternative 3.

testsuite/ChangeLog:

    PR target/64688
    * g++.dg/pr64688.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/pr64688.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/sse.md
    trunk/gcc/testsuite/ChangeLog

[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 22 20:25:23 2015
New Revision: 220012

URL: https://gcc.gnu.org/viewcvs?rev=220012&root=gcc&view=rev
Log:
2015-22-01  Uros Bizjak  <ubizjak@gmail.com>

    PR target/64688
    PR target/64477
    (*vec_dup<mode>): Use (Yi/$r) constraints for alternative 1.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/sse.md

[Bug target/64477] [4.9 Regression] x86 sse unnecessary GPR spill

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.9/5 Regression] x86 sse  |[4.9 Regression] x86 sse
                   |unnecessary GPR spill       |unnecessary GPR spill

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Assuming fixed on the trunk then.

[Bug target/64477] [4.9 Regression] x86 sse unnecessary GPR spill

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.9.3                       |5.0

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
The fix is too risky for release branches (4.9-), where RA won't perform a r->m
fixup on disabled alternative if Yi is used.

The gcc will generate a dead store for TARGET_INTER_UNIT_MOVES_TO_VEC targets
with vec_set<mode>_0, which is a minor issue. -mtune=generic generates correct
code, since TARGET_INTER_UNIT_MOVES_TO_VEC is disabled in this case.
>From gcc-bugs-return-476019-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 04 18:54:08 2015
Return-Path: <gcc-bugs-return-476019-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3500 invoked by alias); 4 Feb 2015 18:54: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 3270 invoked by uid 48); 4 Feb 2015 18:54:04 -0000
From: "vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64907] Suboptimal code (saving rbx on stack in order to save another reg in rbx)
Date: Wed, 04 Feb 2015 18:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vmakarov 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: cc
Message-ID: <bug-64907-4-DFxvLTP2q3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64907-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64907-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: 2015-02/txt/msg00352.txt.bz2
Content-length: 2613

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

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

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

--- Comment #2 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #1)
> Still happens with 5.0.

It is an interesting case but I don't think it will be fixed for GCC-5.0.  It
is hard for me to decide how to fix it.  But even if I knew how do it it would
need a lot of changes in RA.

Before LRA we have:

 2: r91:SI=di:SI
    REG_DEAD di:SI
 3: NOTE_INSN_FUNCTION_BEG
 6: r92:SI=zero_extend(r91:SI#0)
 7: di:SI=r92:SI
   REG_DEAD r92:SI
 8: call [`put_16bit'] argc:0
   REG_DEAD di:SI
   REG_CALL_DECL `put_16bit'
 9: {r93:SI=r91:SI 0>>0x10;clobber flags:CC;}
   REG_DEAD r91:SI
   REG_UNUSED flags:CC
10: di:SI=r93:SI
   REG_DEAD r93:SI
11: call [`put_16bit'] argc:0

P91 gets bx which is saved on in prologue/epilogue according to ABI.  P91 can
not get di because of the conflict with its usage in insn range [7..8].

If we spill p91, we get the same code as before

    2: bx:SI=di:SI
   19: NOTE_INSN_DELETED
    3: NOTE_INSN_FUNCTION_BEG
    6: di:SI=zero_extend(bx:HI)
    8: call [`put_16bit'] argc:0
      REG_CALL_DECL `put_16bit'
   16: di:SI=bx:SI
    9: {di:SI=di:SI 0>>0x10;clobber flags:CC;}
   11: call [`put_16bit'] argc:0
      REG_CALL_DECL `put_16bit'
   12: barrier

That is because of inheritance in LRA.  If we spill p91 and prohibit the
inheritance, we get even worse code

  2: [sp:DI+0xc]=di:SI
  3: NOTE_INSN_FUNCTION_BEG
  6: di:SI=zero_extend([sp:DI+0xc])
  8: call [`put_16bit'] argc:0
    REG_CALL_DECL `put_16bit'
 16: di:SI=[sp:DI+0xc]
  9: {di:SI=di:SI 0>>0x10;clobber flags:CC
 11: call [`put_16bit'] argc:0
    REG_CALL_DECL `put_16bit'
 12: barrier

  I don't think that the PR is important.  If we already used ebx somewhere (it
means code with higher register pressure), the code would be ideal because ebx
is already saved for other purposes.  So it is mostly a problem for such small
functions only.

  Currently I see two solutions: implementation of splitting in IRA which will
be complicated or propagating di from insn 2 to insn 6 in the later code by
some later pass.  It would be even more complicated as we need somehow to
decide that IRA should spill p91 and don't do inheritance for it in LRA.

  Still I'll think about how to fix it in LRA.  But again most probably the PR
will be not fixed for GCC-5.0.