On October 2, 2014 9:50:45 AM CEST, Jakub Jelinek wrote:
>On Thu, Oct 02, 2014 at 11:15:10AM +0400, Evgeny wrote:
>> Hold on. The patch has a conflict with previously approved here.
>
>Which?
>
>In any case, I've already committed the patch.
>
>That said, if what you care now about is pr52252-atom
On Thu, Oct 02, 2014 at 11:15:10AM +0400, Evgeny wrote:
> Hold on. The patch has a conflict with previously approved here.
Which?
In any case, I've already committed the patch.
That said, if what you care now about is pr52252-atom.c with -O2
-ftree-vectorize -mavx2, let's look at all the permuta
On Wed, Oct 1, 2014 at 10:43 PM, Jakub Jelinek wrote:
> > For PR62128, IMHO the right fix is attached. Note, this is again covered
> > in vshuf-*.c tests (test 22 in both vshuf-v32*.c and vshuf-v16*.c).
> > With that attached patch, pr62128.c (aka test_22 in vshuf-v32qi.c), changes:
> > -
On Wed, Oct 01, 2014 at 04:12:15PM +0200, Jakub Jelinek wrote:
> For PR62128, IMHO the right fix is attached. Note, this is again covered
> in vshuf-*.c tests (test 22 in both vshuf-v32*.c and vshuf-v16*.c).
> With that attached patch, pr62128.c (aka test_22 in vshuf-v32qi.c), changes:
> - v
On Wed, Oct 1, 2014 at 2:56 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 02:25:01PM +0200, Uros Bizjak wrote:
>> OK.
>
> And now the expand_vec_perm_palignr improvement, tested
> with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \
> RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c
On Wed, Oct 1, 2014 at 4:12 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 03:09:59PM +0200, Uros Bizjak wrote:
>> > 2014-10-01 Jakub Jelinek
>> >
>> > * config/i386/i386.c (expand_vec_perm_palignr): Handle
>> > 256-bit vectors for TARGET_AVX2.
>>
>> Please mention PR 62128
On Wed, Oct 01, 2014 at 03:09:59PM +0200, Uros Bizjak wrote:
> > 2014-10-01 Jakub Jelinek
> >
> > * config/i386/i386.c (expand_vec_perm_palignr): Handle
> > 256-bit vectors for TARGET_AVX2.
>
> Please mention PR 62128 and include the testcase from the PR. Also,
> please add a ve
On Wed, Oct 1, 2014 at 2:56 PM, Jakub Jelinek wrote:
> And now the expand_vec_perm_palignr improvement, tested
> with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \
> RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
> E.g.
> typedef unsigned long long V __attribute__ ((vector_size (32
On Wed, Oct 01, 2014 at 02:25:01PM +0200, Uros Bizjak wrote:
> OK.
And now the expand_vec_perm_palignr improvement, tested
with GCC_TEST_RUN_EXPENSIVE=1 make check-gcc \
RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
E.g.
typedef unsigned long long V __attribute__ ((vector_size
On Wed, Oct 1, 2014 at 2:17 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 01:45:54PM +0200, Uros Bizjak wrote:
>> OK.
>
> Thanks. Second step is a tiny optimization, for the
> simplified 122 (now 24) vshuf-v4di.c testcase:
> typedef unsigned long long V __attribute__ ((vector_size (32)));
>
On Wed, Oct 01, 2014 at 01:45:54PM +0200, Uros Bizjak wrote:
> OK.
Thanks. Second step is a tiny optimization, for the
simplified 122 (now 24) vshuf-v4di.c testcase:
typedef unsigned long long V __attribute__ ((vector_size (32)));
V a, b, c, d;
int
main ()
{
int i;
for (i = 0; i < 4; ++i)
On Wed, Oct 1, 2014 at 1:38 PM, Jakub Jelinek wrote:
>> That doesn't compile, will post a new version; got interrupted when
>> I found that in
>> GCC_TEST_RUN_EXPENSIVE=1 make check-gcc
>> RUNTESTFLAGS='--target_board=unix/-mavx2 dg-torture.exp=vshuf*.c'
>> one test is miscompiled even with unpa
On Wed, Oct 01, 2014 at 12:35:14PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 12:28:51PM +0200, Uros Bizjak wrote:
> > On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko
> > wrote:
> > > Getting back to initial patch, is it ok?
> >
> > IMO, we should start with Jakub's proposed patch
This is not a fix for the case { 1, 2, 3, ..., 31, 0 }. This patch is
an extension of expand_vec_perm_palignr on AVX2 case.
For the case { 1, 2, 3, ..., 31, 0 } we should use separate
function/pattern. I like split as it is similar to already handled SSE
byte rotate {1,2,3,.,15, 0}: ssse3_palig
On Wed, Oct 01, 2014 at 12:28:51PM +0200, Uros Bizjak wrote:
> On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko
> wrote:
> > Getting back to initial patch, is it ok?
>
> IMO, we should start with Jakub's proposed patch [1]
>
> [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00010.html
Tha
On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko wrote:
> Getting back to initial patch, is it ok?
IMO, we should start with Jakub's proposed patch [1]
[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00010.html
Uros.
> It fixes gcc.target/i386/pr52252-atom.c for AVX2 make check.
> X86 boo
Getting back to initial patch, is it ok?
It fixes gcc.target/i386/pr52252-atom.c for AVX2 make check.
X86 bootstrap is also ok.
2014-10-01 Evgeny Stupachenko
* config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2
PALINGR instruction.
* config/i386/i386.c (ix
The test in pr62128 is exactly TEST 22 from
gcc.dg/torture/vshuf-v32qi.c. It will check if the pattern is correct
or not.
Resubmitting patch looks good as current mail thread is already too complicated.
On Wed, Sep 17, 2014 at 6:49 PM, H.J. Lu wrote:
> On Wed, Sep 17, 2014 at 6:01 AM, Evgeny Stup
On Wed, Sep 17, 2014 at 6:01 AM, Evgeny Stupachenko wrote:
> It fix "gcc.target/i386/pr52252-atom.c" in core-avx2 make check and pr62128.
>
I suggest you resubmit the patch as a bug fix for pr62128 with
testcases from pr62128 as well as gcc.target/i386/pr52252-atom.c.
--
H.J.
It fix "gcc.target/i386/pr52252-atom.c" in core-avx2 make check and pr62128.
On Tue, Sep 16, 2014 at 6:51 PM, H.J. Lu wrote:
> On Tue, Sep 16, 2014 at 6:15 AM, Evgeny Stupachenko
> wrote:
>> PING 2
>>
>> On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko
>> wrote:
>>> PING
>>>
>>> On Wed, Aug
On Tue, Sep 16, 2014 at 6:15 AM, Evgeny Stupachenko wrote:
> PING 2
>
> On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko wrote:
>> PING
>>
>> On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko
>> wrote:
>>> The rotate insn appeared right after expand.
>>> I've done it similar to define_insn_
PING 2
On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko wrote:
> PING
>
> On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko
> wrote:
>> The rotate insn appeared right after expand.
>> I've done it similar to define_insn_and_split "*avx_vperm_broadcast_".
>> I don't see any potential losses
PING
On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko wrote:
> The rotate insn appeared right after expand.
> I've done it similar to define_insn_and_split "*avx_vperm_broadcast_".
> I don't see any potential losses on splitting that after reload.
>
> On Tue, Aug 26, 2014 at 8:29 PM, Richard H
The rotate insn appeared right after expand.
I've done it similar to define_insn_and_split "*avx_vperm_broadcast_".
I don't see any potential losses on splitting that after reload.
On Tue, Aug 26, 2014 at 8:29 PM, Richard Henderson wrote:
> On 08/26/2014 05:59 AM, Evgeny Stupachenko wrote:
>> +(d
On 08/26/2014 05:59 AM, Evgeny Stupachenko wrote:
> +(define_insn_and_split "avx2_rotate_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"
> + [(
That is covered by a separate part of the patch:
(make check and bootstrap passed: 2 new passes for core-avx2)
is it ok?
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index d6155cf..68ee65a 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -81,6 +81,7 @@
;; For
On Thu, Aug 14, 2014 at 1:08 AM, Evgeny Stupachenko wrote:
> Ping.
>
> On Thu, Jul 10, 2014 at 7:29 PM, Evgeny Stupachenko
> wrote:
>> On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson wrote:
>>> On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
-expand_vec_perm_palignr (struct expand_vec_
Ping.
On Thu, Jul 10, 2014 at 7:29 PM, Evgeny Stupachenko wrote:
> On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson wrote:
>> On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
>>> -expand_vec_perm_palignr (struct expand_vec_perm_d *d)
>>> +expand_vec_perm_palignr (struct expand_vec_perm_d *d, i
On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson wrote:
> On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
>> -expand_vec_perm_palignr (struct expand_vec_perm_d *d)
>> +expand_vec_perm_palignr (struct expand_vec_perm_d *d, int insn_num)
>
> insn_num might as well be "bool avx2", since it's only
On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
> -expand_vec_perm_palignr (struct expand_vec_perm_d *d)
> +expand_vec_perm_palignr (struct expand_vec_perm_d *d, int insn_num)
insn_num might as well be "bool avx2", since it's only ever set to two values.
> - /* Even with AVX, palignr only oper
2014-07-04 Evgeny Stupachenko
* config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2
PALINGR instruction.
* config/i386/i386.c (ix86_expand_vec_perm_const_1): Add palignr try
for AVX2.
On Fri, Jul 4, 2014 at 3:22 PM, Uros Bizjak wrote:
> On Thu, Jul
On Thu, Jul 3, 2014 at 11:53 AM, Evgeny Stupachenko wrote:
> The "expand_vec_perm_palignr" is similar for SSSE3 and AVX2 cases,
> but AVX2 requires more instructions to complete the scheme.
>
> The patch below adds AVX2 support for six instructions, leaving SSSE3 for two.
> Is it ok?
ChangeLog
The "expand_vec_perm_palignr" is similar for SSSE3 and AVX2 cases,
but AVX2 requires more instructions to complete the scheme.
The patch below adds AVX2 support for six instructions, leaving SSSE3 for two.
Is it ok?
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2cffcef..70f
On 05/05/2014 09:49 AM, Evgeny Stupachenko wrote:
> @@ -42946,6 +42948,10 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
>if (expand_vec_perm_pshufb (d))
> return true;
>
> + /* Try the AVX2 vpshufb. */
> + if (expand_vec_perm_vpshufb2_vpermq (d))
> +return true;
Why is this h
Ping.
On Mon, May 5, 2014 at 8:49 PM, Evgeny Stupachenko wrote:
> Is the following patch ok? It passes bootstrap and make check.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 88142a8..91f6f21 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -428
Is the following patch ok? It passes bootstrap and make check.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 88142a8..91f6f21 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42807,6 +42807,8 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
return
On 04/28/2014 01:43 PM, Evgeny Stupachenko wrote:
> Agree on checks:
>
> /* PALIGNR of 2 128-bits registers takes only 1 instrucion.
> Requires SSSE3. */
> if (GET_MODE_SIZE (d->vmode) == 16)
> {
> if(!TARGET_SSSE3)
> return false;
> }
> /* PALIGNR of 2 256-bits r
Agree on checks:
/* PALIGNR of 2 128-bits registers takes only 1 instrucion.
Requires SSSE3. */
if (GET_MODE_SIZE (d->vmode) == 16)
{
if(!TARGET_SSSE3)
return false;
}
/* PALIGNR of 2 256-bits registers on AVX2 costs only 2 instructions:
PERM and PALIGNR. It
On Mon, Apr 28, 2014 at 9:08 PM, H.J. Lu wrote:
> On Mon, Apr 28, 2014 at 9:48 AM, Evgeny Stupachenko
> wrote:
>> Hi,
>>
>> The patch enables use of "palignr with perm" instead of "2 pshufb, or
>> and perm" at AVX2 for some cases.
>>
>> Bootstrapped and passes make check on x86.
>>
>> Is it ok?
On 04/28/2014 09:48 AM, Evgeny Stupachenko wrote:
> - /* Even with AVX, palignr only operates on 128-bit vectors. */
> - if (!TARGET_SSSE3 || GET_MODE_SIZE (d->vmode) != 16)
> + /* PALIGNR of 2 256-bits registers on AVX2 costs only 2 instructions:
> + PERM and PALIGNR. It is more profitabl
On Mon, Apr 28, 2014 at 9:48 AM, Evgeny Stupachenko wrote:
> Hi,
>
> The patch enables use of "palignr with perm" instead of "2 pshufb, or
> and perm" at AVX2 for some cases.
>
> Bootstrapped and passes make check on x86.
>
> Is it ok?
>
> 2014-04-28 Evgeny Stupachenko
>
> * config/i386
Hi,
The patch enables use of "palignr with perm" instead of "2 pshufb, or
and perm" at AVX2 for some cases.
Bootstrapped and passes make check on x86.
Is it ok?
2014-04-28 Evgeny Stupachenko
* config/i386/i386.c (expand_vec_perm_1): Try AVX2 vpshufb.
* config/i386/i386.c (ex
42 matches
Mail list logo
