https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856
--- Comment #3 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:62d08a67c83b4a089866c6d19e82d70ee5b8aed1 commit r14-992-g62d08a67c83b4a089866c6d19e82d70ee5b8aed1 Author: Jakub Jelinek <ja...@redhat.com> Date: Fri May 19 12:57:31 2023 +0200 tree-ssa-math-opts: Pattern recognize hand written __builtin_mul_overflow_p with same unsigned types even when target just has highpart umul [PR101856] As can be seen on the following testcase, we pattern recognize it on i?86/x86_64 as return __builtin_mul_overflow_p (x, y, 0UL) and avoid that way the extra division, but don't do it e.g. on aarch64 or ppc64le, even when return __builtin_mul_overflow_p (x, y, 0UL); actually produces there better code. The reason for testing the presence of the optab handler is to make sure the generated code for it is short to ensure we don't actually pessimize code instead of optimizing it. But, we have one case that the internal-fn.cc .MUL_OVERFLOW expansion handles nicely, and that is when arguments/result is the same mode TYPE_UNSIGNED type, we only use IMAGPART_EXPR of it (i.e. __builtin_mul_overflow_p rather than __builtin_mul_overflow) and umul_highpart_optab supports the particular mode, in that case we emit comparison of the highpart umul result against zero. So, the following patch matches what we do in internal-fn.cc and also pattern matches __builtin_mul_overflow_p if 1) we only need the flag whether it overflowed (i.e. !use_seen) 2) it is unsigned (i.e. !cast_stmt) 3) umul_highpart is supported for the mode 2023-05-19 Jakub Jelinek <ja...@redhat.com> PR tree-optimization/101856 * tree-ssa-math-opts.cc (match_arith_overflow): Pattern detect unsigned __builtin_mul_overflow_p even when umulv4_optab doesn't support it but umul_highpart_optab does. * gcc.dg/tree-ssa/pr101856.c: New test.
