[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Kewen Lin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Kewen Lin --- Should be fixed on latest trunk.
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #13 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:b343a29dbcbfc5eaca11243ac603a1e5b48630f3 commit r12-4762-gb343a29dbcbfc5eaca11243ac603a1e5b48630f3 Author: Kewen Lin Date: Thu Oct 28 01:11:56 2021 -0500 rs6000: Fix ICE of vect cost related to V1TI [PR102767] As PR102767 shows, the commit r12-3482 exposed one ICE in function rs6000_builtin_vectorization_cost. We claims V1TI supports movmisalign on rs6000 (See define_expand "movmisalign"), so it return true in rs6000_builtin_support_vector_misalignment for misalign 8. Later in the cost querying function rs6000_builtin_vectorization_cost, we don't have the arms to handle the V1TI input under (TARGET_VSX && TARGET_ALLOW_MOVMISALIGN). The proposed fix is to add the consideration for V1TI, simply make it as the cost for doubleword which is apparently bigger than the cost of scalar, won't have the vectorization to happen, just to keep consistency and avoid ICE. Another thought is to not support movmisalign for V1TI, but it sounds like a bad idea since it doesn't match the reality. Note that this patch also fixes up the wrong indentations around. gcc/ChangeLog: PR target/102767 * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Consider V1T1 mode for unaligned load and store. gcc/testsuite/ChangeLog: PR target/102767 * gcc.target/powerpc/ppc-fortran/pr102767.f90: New file.
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #12 from Kewen Lin --- The patch was posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582454.html
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #11 from Martin Liška --- *** Bug 102847 has been marked as a duplicate of this bug. ***
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Andrew Pinski changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- *** Bug 102372 has been marked as a duplicate of this bug. ***
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #9 from Kewen Lin --- (In reply to Richard Biener from comment #8) > the backend says it can support misaligned V1TI via > rs6000_builtin_support_vector_misalignment: > > rs6000_builtin_support_vector_misalignment (mode=E_V1TImode, > type=, > misalignment=8, is_packed=false) at > ../../src/trunk/gcc/config/rs6000/rs6000.c:5069 > ... > /* VSX supports word-aligned vector. */ > if (misalignment % 4 == 0) > return true; > > so the vectorizer classifies it as dr_unaligned_supported and we of course > are then allowed to cost the supported unaligned store but the cost > hook doesn't consider elements == 1. > > Now, we probably should avoid 1-lane vector vectorization in BB vect but > that's > a different story. Yes, it's inconsistent between the hook and costing query. I'll make a patch.
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #8 from Richard Biener --- the backend says it can support misaligned V1TI via rs6000_builtin_support_vector_misalignment: rs6000_builtin_support_vector_misalignment (mode=E_V1TImode, type=, misalignment=8, is_packed=false) at ../../src/trunk/gcc/config/rs6000/rs6000.c:5069 ... /* VSX supports word-aligned vector. */ if (misalignment % 4 == 0) return true; so the vectorizer classifies it as dr_unaligned_supported and we of course are then allowed to cost the supported unaligned store but the cost hook doesn't consider elements == 1. Now, we probably should avoid 1-lane vector vectorization in BB vect but that's a different story.
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #7 from Kewen Lin --- (In reply to Segher Boessenkool from comment #6) > (In reply to Richard Earnshaw from comment #5) > > We have the type > > > type > size > > unit-size > > and movmisalign pattern is enabled for this. > > > > but the vectorization cost doesn't handle the case of elements=1, which is > > the case when mode is TImode. > > > > So I think this is an inconsistency in the rs6000 backend - either add > > costing support for single elements or disable the movmisalign code in this > > case. > > But TImode is a scalar type, not a vector type, so it should hit one of the > early-outs at the top of rs6000_builtin_vectorization_cost? for rs6000, the scalar type is uint128_t, the vectorized type is vector(1) uint128_t unit-size align:128 warn_if_not_align:0 symtab:0 alias-set 13 canonical-type 0x751b0bd0 precision:128 min max > unsigned V1TI size unit-size align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x751b5dd8 nunits:1> We have the movmisalign support for V1TI #define HAVE_movmisalignv4si (VECTOR_MEM_VSX_P (V4SImode) && TARGET_ALLOW_MOVMISALIGN) #define HAVE_movmisalignv4sf (VECTOR_MEM_VSX_P (V4SFmode) && TARGET_ALLOW_MOVMISALIGN) #define HAVE_movmisalignv2di (VECTOR_MEM_VSX_P (V2DImode) && TARGET_ALLOW_MOVMISALIGN) #define HAVE_movmisalignv2df (VECTOR_MEM_VSX_P (V2DFmode) && TARGET_ALLOW_MOVMISALIGN) #define HAVE_movmisalignv1ti (VECTOR_MEM_VSX_P (V1TImode) && TARGET_ALLOW_MOVMISALIGN) The misalign in the failure is 8, it makes the hook rs6000_builtin_support_vector_misalignment return true. The loop vectorization fails to vectorize for V1TI due to the resulted vectorization factor is 1. But for this failure it's BB slp, it looks allowable to query the cost with V1TI. I think Richard E. is right, it's a rs6000 specific issue.
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 --- Comment #6 from Segher Boessenkool --- (In reply to Richard Earnshaw from comment #5) > We have the type > type size > unit-size > and movmisalign pattern is enabled for this. > > but the vectorization cost doesn't handle the case of elements=1, which is > the case when mode is TImode. > > So I think this is an inconsistency in the rs6000 backend - either add > costing support for single elements or disable the movmisalign code in this > case. But TImode is a scalar type, not a vector type, so it should hit one of the early-outs at the top of rs6000_builtin_vectorization_cost?
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Andrew Pinski changed: What|Removed |Added Summary|ICE in |[12 Regression] ICE in |rs6000_builtin_vectorizatio |rs6000_builtin_vectorizatio |n_cost, at |n_cost, at |config/rs6000/rs6000.c:5216 |config/rs6000/rs6000.c:5216 Host|x86_64-linux-gnu| Target Milestone|--- |12.0 Keywords|needs-bisection |
