On Wed, Oct 1, 2014 at 10:43 PM, Jakub Jelinek ja...@redhat.com 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 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
On October 2, 2014 9:50:45 AM CEST, Jakub Jelinek ja...@redhat.com 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
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 evstu...@gmail.com
* config/i386/i386.c (expand_vec_perm_palignr): Extend to use AVX2
PALINGR instruction.
*
On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko evstu...@gmail.com 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
On Wed, Oct 01, 2014 at 12:28:51PM +0200, Uros Bizjak wrote:
On Wed, Oct 1, 2014 at 12:16 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
Getting back to initial patch, is it ok?
IMO, we should start with Jakub's proposed patch [1]
[1]
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}:
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 evstu...@gmail.com
wrote:
Getting back to initial patch, is it ok?
IMO, we should start with Jakub's
On Wed, Oct 1, 2014 at 1:38 PM, Jakub Jelinek ja...@redhat.com 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
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 2:17 PM, Jakub Jelinek ja...@redhat.com 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
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:56 PM, Jakub Jelinek ja...@redhat.com 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__
On Wed, Oct 01, 2014 at 03:09:59PM +0200, Uros Bizjak wrote:
2014-10-01 Jakub Jelinek ja...@redhat.com
* 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
On Wed, Oct 1, 2014 at 4:12 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Oct 01, 2014 at 03:09:59PM +0200, Uros Bizjak wrote:
2014-10-01 Jakub Jelinek ja...@redhat.com
* config/i386/i386.c (expand_vec_perm_palignr): Handle
256-bit vectors for TARGET_AVX2.
Please
On Wed, Oct 1, 2014 at 2:56 PM, Jakub Jelinek ja...@redhat.com 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
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:
-
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 hjl.to...@gmail.com wrote:
On Tue, Sep 16, 2014 at 6:15 AM, Evgeny Stupachenko evstu...@gmail.com
wrote:
PING 2
On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko
On Wed, Sep 17, 2014 at 6:01 AM, Evgeny Stupachenko evstu...@gmail.com 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.
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 hjl.to...@gmail.com wrote:
On Wed, Sep 17, 2014 at
PING 2
On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
PING
On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko evstu...@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
On Tue, Sep 16, 2014 at 6:15 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
PING 2
On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
PING
On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
The rotate insn appeared right after expand.
PING
On Wed, Aug 27, 2014 at 7:50 PM, Evgeny Stupachenko evstu...@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
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 r...@redhat.com wrote:
On 08/26/2014 05:59 AM, Evgeny
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 08/26/2014 05:59 AM, Evgeny Stupachenko wrote:
+(define_insn_and_split avx2_rotatemode_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
Ping.
On Thu, Jul 10, 2014 at 7:29 PM, Evgeny Stupachenko evstu...@gmail.com wrote:
On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson r...@redhat.com 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
On Thu, Aug 14, 2014 at 1:08 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
Ping.
On Thu, Jul 10, 2014 at 7:29 PM, Evgeny Stupachenko evstu...@gmail.com
wrote:
On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson r...@redhat.com wrote:
On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
On Mon, Jul 7, 2014 at 6:40 PM, Richard Henderson r...@redhat.com 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
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 operates
On Thu, Jul 3, 2014 at 11:53 AM, Evgeny Stupachenko evstu...@gmail.com 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?
2014-07-04 Evgeny Stupachenko evstu...@gmail.com
* 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
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
Ping.
On Mon, May 5, 2014 at 8:49 PM, Evgeny Stupachenko evstu...@gmail.com 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
+++
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 here?
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)
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 evstu...@gmail.com
* config/i386/i386.c (expand_vec_perm_1): Try AVX2 vpshufb.
*
On Mon, Apr 28, 2014 at 9:48 AM, Evgeny Stupachenko evstu...@gmail.com 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 evstu...@gmail.com
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 profitable
On Mon, Apr 28, 2014 at 9:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Mon, Apr 28, 2014 at 9:48 AM, Evgeny Stupachenko evstu...@gmail.com
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
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 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 registers
42 matches
Mail list logo
