[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bff948aa337807260344c83ac9079d6386410094
commit r10-6273-gbff948aa337807260344c83ac9079d6386410094
Author: Jakub Jelinek
Date: Tue Jan 28 08:46:23 2020 +0100
i386: Fix ix86_fold_builtin shift folding [PR93418]
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.
2020-01-28 Jakub Jelinek
PR target/93418
* config/i386/i386.c (ix86_fold_builtin) : 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.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #8 from Devin Hussey --- Seems to work. ~ $ ~/gcc-test/bin/x86_64-pc-cygwin-gcc.exe -mavx2 -O3 _mm_sllv_bug.c ~ $ ./a.exe Without optimizations (correct result): 8000 fff8 With optimizations (incorrect result): 8000 fff8 ~ $ And checking the assembly, the shifts are constant propagated. The provided test file also passes.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 47717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47717=edit gcc10-pr93418.patch Untested fix.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #6 from Jakub Jelinek --- I'll have a look.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|10.0|9.3
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Devin Hussey changed: What|Removed |Added Build||2020-01-24 0:00 --- Comment #5 from Devin Hussey --- Finally got GCC to build after it was throwing a fit. I can confirm that the regression is in that commit. g:28a8a768ebef5e31f950013f1b48b14c008b4b3b works correctly, g:6a03477e85e1b097ed6c0b86c76436de575aef04 does not.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- (In reply to Devin Hussey from comment #3) > I think I found the culprit commit. > > Haven't set up a GCC build tree yet, though. > > https://github.com/gcc-mirror/gcc/commit/ > a51c4926712307787d133ba50af8c61393a9229b g:6a03477e85e1b097ed6c0b86c76436de575aef04 for the new git.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #3 from Devin Hussey --- I think I found the culprit commit. Haven't set up a GCC build tree yet, though. https://github.com/gcc-mirror/gcc/commit/a51c4926712307787d133ba50af8c61393a9229b
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #2 from Andrew Pinski --- The bug is most likely inside ix86_fold_builtin.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-24
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
From .ccp1:
Visiting statement:
_17 = VIEW_CONVERT_EXPR(shifts_13);
which is likely CONSTANT
Match-and-simplified VIEW_CONVERT_EXPR(shifts_13) to { 16, 31,
-34, 3 }
Lattice value changed to CONSTANT { 16, 31, -34, 3 }. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_18 = VIEW_CONVERT_EXPR(vals_11);
which is likely CONSTANT
Match-and-simplified VIEW_CONVERT_EXPR(vals_11) to { -1, -1, -1,
-1 }
Lattice value changed to CONSTANT { -1, -1, -1, -1 }. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_19 = __builtin_ia32_psllv4si (_18, _17);
which is likely CONSTANT
Lattice value changed to CONSTANT { -65536, -65536, -65536, -65536 }. Adding
SSA edges to worklist.
marking stmt to be not simulated again
