| Message ID | 008401d86d27$d74f9a20$85eece60$@nextmovesoftware.com |
|---|---|
| State | New |
| Headers | show |
| Series | Simplify vec_unpack of uniform_vector_p constructors in match.pd. | expand |
On Sat, May 21, 2022 at 5:31 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform > constructor or vec_duplicate operand. The motivation is from PR 105621 > where after optimization, we're left with: > > vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; > vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; > > It turns out that there are no constant folding/simplification patterns > in match.pd, but the above can be simplified further to the equivalent: > > _20 = (long int) c_8(D); > vect_iftmp.7_4 = [vec_duplicate_expr] _20; > > which on x86-64 results in one less instruction, replacing pshufd $0 > then punpackhq, with punpcklqdq. This transformation is also useful > for helping CSE to spot that unpack_hi and unpack_lo are equivalent. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check with no new failures. Ok for mainline? I think we need a way to query whether the target can do a VEC_DUPLICATE_EXPR. Currently we only ever have them for VL vectors and expand via expand_vector_broadcast which eventually simply gives up when there's no vec_duplicate or vec_init optabs suitable. IIRC with the VEC_PERM extension we should be able to handle VEC_DUPLICATE via VEC_PERM? (but we don't yet accept a scalar input, just V1<mode>?) I see most targets have picked up vec_duplicate but sparc, but still we'd need to check the specific mode. I think we can disregart vec_init checking and only apply the transforms when vec_duplicate is available. Richard. > > 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR > of uniform vector constructors and vec_duplicate. > > gcc/testsuite/ChangeLog > * g++.dg/vect/pr105621.cc: New test case. > > > Thanks in advance, > Roger > -- >
Richard Biener <richard.guenther@gmail.com> writes: > On Sat, May 21, 2022 at 5:31 PM Roger Sayle <roger@nextmovesoftware.com> wrote: >> This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform >> constructor or vec_duplicate operand. The motivation is from PR 105621 >> where after optimization, we're left with: >> >> vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; >> vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; >> >> It turns out that there are no constant folding/simplification patterns >> in match.pd, but the above can be simplified further to the equivalent: >> >> _20 = (long int) c_8(D); >> vect_iftmp.7_4 = [vec_duplicate_expr] _20; >> >> which on x86-64 results in one less instruction, replacing pshufd $0 >> then punpackhq, with punpcklqdq. This transformation is also useful >> for helping CSE to spot that unpack_hi and unpack_lo are equivalent. >> >> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap >> and make -k check with no new failures. Ok for mainline? > > I think we need a way to query whether the target can do a VEC_DUPLICATE_EXPR. > Currently we only ever have them for VL vectors and expand via > expand_vector_broadcast which eventually simply gives up when there's no > vec_duplicate or vec_init optabs suitable. > > IIRC with the VEC_PERM extension we should be able to handle > VEC_DUPLICATE via VEC_PERM? (but we don't yet accept a scalar > input, just V1<mode>?) Yeah, should be possible. Not sure whether it would really help though. A VEC_PERM_EXPR with only one scalar argument could only have one sensible permute mask[*], so there'd be a bit of false generality. Maybe allowing scalar arguments would be more useful for 2 distinct scalar arguments, but then I guess the question is: why stop at 2? So if we go down the route of accepting scalars, it might be more consistent to make VEC_PERM_EXPR support any number of operands and use it as a replacement for CONSTRUCTOR as well. Thanks, Richard [*] At least until we support “don't care” elements. However, like I mentioned before, I'd personally prefer a “don't care” mask to be a separate operand, rather than treating something like -1 as a special value. Special values like that don't really fit the current encoding scheme for VL constants, but a separate mask would. A separate don't-care mask would also work for variable permute masks. > > I see most targets have picked up vec_duplicate but sparc, but still > we'd need to check the specific mode. I think we can disregart > vec_init checking and only apply the transforms when vec_duplicate > is available. > > Richard. > >> >> 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> >> >> gcc/ChangeLog >> * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR >> of uniform vector constructors and vec_duplicate. >> >> gcc/testsuite/ChangeLog >> * g++.dg/vect/pr105621.cc: New test case. >> >> >> Thanks in advance, >> Roger >> -- >>
On Mon, Jun 6, 2022 at 11:06 AM Richard Sandiford <richard.sandiford@arm.com> wrote: > > Richard Biener <richard.guenther@gmail.com> writes: > > On Sat, May 21, 2022 at 5:31 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > >> This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform > >> constructor or vec_duplicate operand. The motivation is from PR 105621 > >> where after optimization, we're left with: > >> > >> vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; > >> vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; > >> > >> It turns out that there are no constant folding/simplification patterns > >> in match.pd, but the above can be simplified further to the equivalent: > >> > >> _20 = (long int) c_8(D); > >> vect_iftmp.7_4 = [vec_duplicate_expr] _20; > >> > >> which on x86-64 results in one less instruction, replacing pshufd $0 > >> then punpackhq, with punpcklqdq. This transformation is also useful > >> for helping CSE to spot that unpack_hi and unpack_lo are equivalent. > >> > >> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > >> and make -k check with no new failures. Ok for mainline? > > > > I think we need a way to query whether the target can do a VEC_DUPLICATE_EXPR. > > Currently we only ever have them for VL vectors and expand via > > expand_vector_broadcast which eventually simply gives up when there's no > > vec_duplicate or vec_init optabs suitable. > > > > IIRC with the VEC_PERM extension we should be able to handle > > VEC_DUPLICATE via VEC_PERM? (but we don't yet accept a scalar > > input, just V1<mode>?) > > Yeah, should be possible. Not sure whether it would really help though. > A VEC_PERM_EXPR with only one scalar argument could only have one sensible > permute mask[*], so there'd be a bit of false generality. > > Maybe allowing scalar arguments would be more useful for 2 distinct > scalar arguments, but then I guess the question is: why stop at 2? > So if we go down the route of accepting scalars, it might be more > consistent to make VEC_PERM_EXPR support any number of operands > and use it as a replacement for CONSTRUCTOR as well. Discussion was hijacked by the '[PATCH]AArch64 relax predicate on load structure load instructions' thread btw. Roger - your eyesopen.com mail bounces, can you fix your MAINTAINERS entry please? Richard. > Thanks, > Richard > > [*] At least until we support “don't care” elements. However, like I > mentioned before, I'd personally prefer a “don't care” mask to be > a separate operand, rather than treating something like -1 as a > special value. Special values like that don't really fit the > current encoding scheme for VL constants, but a separate mask would. > > A separate don't-care mask would also work for variable permute masks. > > > > I see most targets have picked up vec_duplicate but sparc, but still > > we'd need to check the specific mode. I think we can disregart > > vec_init checking and only apply the transforms when vec_duplicate > > is available. > > > > Richard. > > > >> > >> 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> > >> > >> gcc/ChangeLog > >> * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR > >> of uniform vector constructors and vec_duplicate. > >> > >> gcc/testsuite/ChangeLog > >> * g++.dg/vect/pr105621.cc: New test case. > >> > >> > >> Thanks in advance, > >> Roger > >> -- > >>
diff --git a/gcc/match.pd b/gcc/match.pd index c2fed9b..753c392 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7800,6 +7800,22 @@ and, (if (TREE_CODE (@0) == SSA_NAME && num_imm_uses (@0) == 2) (minus (mult (vec_perm @1 @1 @3) @2) @4))) +/* VEC_UNPACK_LO_EXPR and friends. */ +(for unpack (vec_unpack_lo vec_unpack_float_lo vec_unpack_fix_trunc_lo + vec_unpack_hi vec_unpack_float_hi vec_unpack_fix_trunc_hi) + opcode (convert float fix_trunc convert float fix_trunc) + (simplify + (unpack CONSTRUCTOR@0) + (with { tree ctor = (TREE_CODE (@0) == SSA_NAME + ? gimple_assign_rhs1 (SSA_NAME_DEF_STMT (@0)) : @0); + tree elt = uniform_vector_p (ctor); + tree eltype = TREE_TYPE (type); } + (if (elt) + (vec_duplicate (opcode:eltype { elt; }))))) + (simplify + (unpack (vec_duplicate @0)) + (with { tree eltype = TREE_TYPE (type); } + (vec_duplicate (opcode:eltype @0))))) /* Match count trailing zeroes for simplify_count_trailing_zeroes in fwprop. The canonical form is array[((x & -x) * C) >> SHIFT] where C is a magic diff --git a/gcc/testsuite/g++.dg/vect/pr105621.cc b/gcc/testsuite/g++.dg/vect/pr105621.cc new file mode 100644 index 0000000..98e8fcd --- /dev/null +++ b/gcc/testsuite/g++.dg/vect/pr105621.cc @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +bool d; + +void test(unsigned short a, int b, unsigned c) { + for (int i = 2; i < 24; i += 3) + d = b ? a ? c : 2086607777901731118 : 0; +} + +/* { dg-final { scan-tree-dump-not "vec_unpack" "optimized" } } */
This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform constructor or vec_duplicate operand. The motivation is from PR 105621 where after optimization, we're left with: vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; It turns out that there are no constant folding/simplification patterns in match.pd, but the above can be simplified further to the equivalent: _20 = (long int) c_8(D); vect_iftmp.7_4 = [vec_duplicate_expr] _20; which on x86-64 results in one less instruction, replacing pshufd $0 then punpackhq, with punpcklqdq. This transformation is also useful for helping CSE to spot that unpack_hi and unpack_lo are equivalent. This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check with no new failures. Ok for mainline? 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR of uniform vector constructors and vec_duplicate. gcc/testsuite/ChangeLog * g++.dg/vect/pr105621.cc: New test case. Thanks in advance, Roger --