From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-464511-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11527 invoked by alias); 20 Oct 2014 12:49:00 -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
Received: (qmail 11493 invoked by uid 48); 20 Oct 2014 12:48:56 -0000
From: "kyukhin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
Date: Mon, 20 Oct 2014 12:50: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: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kyukhin 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: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63594-4-7j8ALRsc8d@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63594-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63594-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-10/txt/msg01532.txt.bz2

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

--- Comment #4 from Kirill Yukhin <kyukhin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 33761 [details]
> WIP patch for discussions
> 
> From what I see, if TARGET_AVX512BW is not defined, then we obviously can't
> use
> ix86_vector_duplicate_value, but need two instructions (either it can be
> QI->V32QI / HI->V16HI broadcast followed by concat of the two parts, or
> QI->V16QI / HI->V8HI broadcast followed by concat of the 4 parts together).
> But, it seems even for -mavx2 or -mavx we actually generate terrible code,
> for -mavx2 there is no point in using 2 instructions when in theory
> vpbroadcast{b,w} should handle it alone just fine.
Right!

> The patch enables all of that, but unfortunately we generate perhaps not so
> good code with it, e.g. for -mavx2 in testchar32, we spill the argument
> always to memory, and then broadcast it from memory, even when vmovd +
> broadcast from register could have been used.
> And in testchar16, for some reason we spill into memory, and broadcast from
> vmovd result (so the spill is totally useless).
I think this is because of subreg:QI of reg:SI.
Before reload we have (for testchar32):
(insn 2 5 3 2 (set (reg:SI 86 [ c ])
        (reg:SI 5 di [ c ])) 1.c:22 90 {*movsi_internal}
     (expr_list:REG_DEAD (reg:SI 5 di [ c ])
        (nil)))
(insn 7 4 12 2 (set (reg:V32QI 88 [ v ])
        (vec_duplicate:V32QI (subreg:QI (reg:SI 86 [ c ]) 0))) 1.c:22 4112
{vec_dupv32qi}
     (expr_list:REG_DEAD (reg:SI 86 [ c ])
        (nil)))

After reload we need to get rid off subreg:
(insn 2 5 3 2 (set (mem/c:SI (plus:DI (reg/f:DI 6 bp)
                (const_int -20 [0xffffffffffffffec])) [8 %sfp+-4 S4 A32])
        (reg:SI 5 di [ c ])) 1.c:22 90 {*movsi_internal}
     (nil))
(insn 7 4 12 2 (set (reg:V32QI 21 xmm0 [orig:88 v ] [88])
        (vec_duplicate:V32QI (mem/c:QI (plus:DI (reg/f:DI 6 bp)
                    (const_int -20 [0xffffffffffffffec])) [8 %sfp+-4 S1 A32])))
1.c:22 4112 {vec_dupv32qi}
     (nil))

> Uros/Kyrill, any thoughts on this?
I like the patch.