On Tue, 2020-01-28 at 00:41 +0100, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because the variable shift left
> operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
> VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
> we call builder.new_unary_operation, builder.encoded_nelts () will be just 1
> and thus we encode the resulting vector as if all the elements were the
> same.
> For non-masked is_vshift, we could perhaps call builder.new_binary_operation
> (TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
> shifts, for non-is_vshift we could perhaps call it too but with args[2]
> instead of args[1], but there is no builder.new_ternary_operation.
> All this stuff is primarily for aarch64 anyway, on x86 we don't have any
> variable length vectors, and it is not a big deal to compute all elements
> and just let builder.finalize () find the most efficient VECTOR_CST
> representation of the vector. So, instead of doing too much, this just
> keeps using new_unary_operation only if only one VECTOR_CST is involved
> (i.e. non-masked shift by constant) and for the rest just compute all elts.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-01-28 Jakub Jelinek <ja...@redhat.com>
>
> PR target/93418
> * config/i386/i386.c (ix86_fold_builtin) <do_shift>: If mask is not
> -1 or is_vshift is true, use new_vector with number of elts npatterns
> rather than new_unary_operation.
>
> * gcc.target/i386/avx2-pr93418.c: New test.
OK.
Jeff
>
