From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-377807-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30532 invoked by alias); 16 Sep 2014 13:15:58 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 30500 invoked by uid 89); 16 Sep 2014 13:15:54 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-yh0-f42.google.com
Received: from mail-yh0-f42.google.com (HELO mail-yh0-f42.google.com) (209.85.213.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 16 Sep 2014 13:15:51 +0000
Received: by mail-yh0-f42.google.com with SMTP id i57so3157401yha.29        for <gcc-patches@gcc.gnu.org>; Tue, 16 Sep 2014 06:15:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.50.198 with SMTP id z46mr2119087yhb.115.1410873349606; Tue, 16 Sep 2014 06:15:49 -0700 (PDT)
Received: by 10.170.202.7 with HTTP; Tue, 16 Sep 2014 06:15:49 -0700 (PDT)
In-Reply-To: <CAOvf_xxr00v6dk=0EfS3ZETStdtT7OfczLD=xJs=-VGqc3nsdw@mail.gmail.com>
References: <CAOvf_xx3-VpgN8YDxJBPvzzNGNykUPoLdU6xThW_QBN7byy5rw@mail.gmail.com>	<535E909A.7040205@redhat.com>	<CAOvf_xygddE6yxkp=+SZtVz+bvVciH5YfH1Cwy1WxdPHCgrbtg@mail.gmail.com>	<535EC233.7000500@redhat.com>	<CAOvf_xxq6PNN2KLpA8yoB2jjgmy-UAOvij_ghgsKPkZnsu2Rkg@mail.gmail.com>	<537A23F7.2060601@redhat.com>	<CAOvf_xwYJpQ0H9=MrLzUd40JDksZ8Tfsks2=8ZW4MfR_wCjU1A@mail.gmail.com>	<53BAB164.7000006@redhat.com>	<CAOvf_xy20vC4h_kzyDAE0D_Pgm-2aoi3C9yxesoT=n4TVcANcg@mail.gmail.com>	<CAOvf_xzsTEtRy+Sz+JaeEZDyd_A7yTqh-kQrpSMNssWdp3hQ3g@mail.gmail.com>	<CAMe9rOrVkSgMCjCNmU7+SSyT-BLLQ6myWfq+K-WjirdzaZtYMw@mail.gmail.com>	<CAOvf_xwh+0j-9YAgJCxKQSoNNJfq9KYr_iSLw=43JhFxAuOfPg@mail.gmail.com>	<53FCB5ED.7040209@redhat.com>	<CAOvf_xygAivauU2_s2dzCKt5nCZ_AbsTXOpj4u+ceg4ffvGhgA@mail.gmail.com>	<CAOvf_xxr00v6dk=0EfS3ZETStdtT7OfczLD=xJs=-VGqc3nsdw@mail.gmail.com>
Date: Tue, 16 Sep 2014 13:15:00 -0000
Message-ID: <CAOvf_xw8+ojk8W6gP_eLBxdvT0rsTLmGsYKzGig4mJ7Y7xUmFA@mail.gmail.com>
Subject: Re: [PATCH 1/2, x86] Add palignr support for AVX2.
From: Evgeny Stupachenko <evstupac@gmail.com>
To: Richard Henderson <rth@redhat.com>, Uros Bizjak <ubizjak@gmail.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, GCC Patches <gcc-patches@gcc.gnu.org>, 	Richard Biener <rguenther@suse.de>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2014-09/txt/msg01288.txt.bz2

PING 2

On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko <evstupac@gmail.com> wrote:
> PING
>
> On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko <evstupac@gmail.com> wrote:
>> The rotate insn appeared right after expand.
>> I've done it similar to define_insn_and_split "*avx_vperm_broadcast_<mode>".
>> I don't see any potential losses on splitting that after reload.
>>
>> On Tue, Aug 26, 2014 at 8:29 PM, Richard Henderson <rth@redhat.com> wrote:
>>> On 08/26/2014 05:59 AM, Evgeny Stupachenko wrote:
>>>> +(define_insn_and_split "avx2_rotate<mode>_perm"
>>>> +  [(set (match_operand:V_256 0 "register_operand" "=&x")
>>>> +      (vec_select:V_256
>>>> +       (match_operand:V_256 1 "register_operand" "x")
>>>> +       (match_parallel 2 "palignr_operand"
>>>> +         [(match_operand 3 "const_int_operand" "n")])))]
>>>> +  "TARGET_AVX2"
>>>> +  "#"
>>>> +  "&& reload_completed"
>>>> +  [(const_int 0)]
>>>
>>> Why are you waiting until after reload to expand this?  It's only the
>>> vec_select parallel that determines which direction the palignr should be done.
>>>
>>> This seems like something you could do during permutation expansion.
>>>
>>>
>>> r~
>>>
>>>