https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Tamar Christina <tnfch...@gcc.gnu.org>: https://gcc.gnu.org/g:d2f9159cfe7ea904e6476cabefea0c6ac9532e29 commit r15-4802-gd2f9159cfe7ea904e6476cabefea0c6ac9532e29 Author: Tamar Christina <tamar.christ...@arm.com> Date: Thu Oct 31 12:50:23 2024 +0000 middle-end: Lower all gconds during vector pattern matching [PR117176] I have been taking a look at boolean handing once more in the vectorizer. There are two situation to consider: 1. when the boolean being created are created from comparing data inputs then for the resulting vector boolean we need to know the vector type and the precision. In this case, when we have an operation such as NOT on the data element, this has to be lowered to XOR because the truncation to the vector precision needs to be explicit. 2. when the boolean being created comes from another boolean operation, then we don't need to lower NOT, as the precision doesn't change. We don't do any lowering for these (as denoted in check_bool_pattern) and instead the precision is copied from the element feeding the boolean statement during VF analysis. For early break gcond lowering in order to correctly handle the second scenario above we punted the lowering of VECT_SCALAR_BOOLEAN_TYPE_P comparisons that were already in the right shape. e.g. e != 0 where e is a boolean does not need any lowering. The issue however is that the statement feeding e may need to be lowered in the case where it's a data expression. This patch changes a bit how we do the lowering. We now always emit an additional compare. e.g. if the input is; if (e != 0) where is a boolean we would punt on thi before, but now we generate f = e != 0 if (f != 0) We then use the same infrastructre as recog_bool to ask it to lower f, and in doing so handle and boolean conversions that need to be lowered. Because we now guarantee that f is an internal def we can also simplify the SLP building code. When e is a boolean, the precision we build for f needs to reflect the precision of the operation feeding e. To get this value we use integer_type_for_mask the same way recog_bool does, and if it's defined (e.g. we have a data conversions somewhere) we pass that precision on instead. This gets us the correct VF on the newly lowered boolean expressions. gcc/ChangeLog: PR tree-optimization/117176 * tree-vect-patterns.cc (vect_recog_gcond_pattern): Lower all gconds. * tree-vect-slp.cc (vect_analyze_slp): No longer check for in vect def. gcc/testsuite/ChangeLog: PR tree-optimization/117176 * gcc.dg/vect/vect-early-break_130-pr117176.c: New test.
