[Bug tree-optimization/101856] New: match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[Bug tree-optimization/101856] New: match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856

            Bug ID: 101856
           Summary: match_arith_overflow checks only
                    mulv4_optab/umulv4_optab  tables when
                    smul_highpart_optab/umul_highpart_optab can produce
                    decent code too
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64-linux-gnu

While looking at 30314, I Noticed aarch64 was not producing MUL_OVERFLOW for
that test. I tested __builtin_umulll_overflow manually and got:
        umulh   x8, x1, x0
        cbz     x8, 

Which is what I had expected.

Original testcase:
typedef __SIZE_TYPE__ size_t;
extern void *malloc(size_t), abort(void);
void *allocate(size_t num, size_t size) {
    size_t total = num * size;

    if (total / size != num) abort();
    /* call malloc, whatever */
    return 0;
}

The code does:

      || (code == MULT_EXPR
          && optab_handler (cast_stmt ? mulv4_optab : umulv4_optab,
                            TYPE_MODE (type)) == CODE_FOR_nothing))

Oh it seems like there could be caching of reading optab_handler in
match_arith_overflow too.

[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-25
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 55109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55109&action=edit
gcc14-pr101856.patch

Untested fix.

[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[cvs-commit at gcc dot gnu.org]

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 <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:62d08a67c83b4a089866c6d19e82d70ee5b8aed1

commit r14-992-g62d08a67c83b4a089866c6d19e82d70ee5b8aed1
Author: Jakub Jelinek <jakub@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  <jakub@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.

[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.