https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:6ad1c1027628f094260037536f6b6fcdb63b5add commit r13-5742-g6ad1c1027628f094260037536f6b6fcdb63b5add Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Feb 8 18:41:21 2023 +0100 vect-patterns: Fix up vect_widened_op_tree [PR108692] The following testcase is miscompiled on aarch64-linux since r11-5160. Given <bb 3> [local count: 955630225]: # i_22 = PHI <i_20(6), 0(5)> # r_23 = PHI <r_19(6), 0(5)> ... a.0_5 = (unsigned char) a_15; _6 = (int) a.0_5; b.1_7 = (unsigned char) b_17; _8 = (int) b.1_7; c_18 = _6 - _8; _9 = ABS_EXPR <c_18>; r_19 = _9 + r_23; ... where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int we first pattern recognize c_18 as patt_34 = (a.0_5) w- (b.1_7); which is still correct, 5/7 are unsigned char subtracted in wider type, but then vect_recog_sad_pattern turns it into SAD_EXPR <a_15, b_17, r_23> which is incorrect, because 15/17 are signed char and so it is sum of absolute signed differences rather than unsigned sum of absolute unsigned differences. The reason why this happens is that vect_recog_sad_pattern calls vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree calls vect_look_through_possible_promotion on the operands of the WIDEN_MINUS_EXPR, which looks through the further casts. vect_look_through_possible_promotion has careful code to stop when there would be nested casts that need to be preserved, but the problem here is that the WIDEN_*_EXPR operation itself has an implicit cast on the operands already - in this case of WIDEN_MINUS_EXPR the unsigned char 5/7 SSA_NAMEs are widened to unsigned short before the subtraction, and vect_look_through_possible_promotion obviously isn't told about that. Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had to look through possible promotions already when creating those and so vect_look_through_possible_promotion again isn't really needed, all we need to do is arrange what that function will do if the operand isn't result of any cast. Other option would be let vect_look_through_possible_promotion know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid that would be much harder. 2023-02-08 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/108692 * tree-vect-patterns.cc (vect_widened_op_tree): If rhs_code is widened_code which is different from code, don't call vect_look_through_possible_promotion but instead just check op is SSA_NAME with integral type for which vect_is_simple_use is true and call set_op on this_unprom. * gcc.dg/pr108692.c: New test.
