[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 gcc-bugzilla@gcc.gnu.org
Wed Aug 11 07:22:15 GMT 2021


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.


More information about the Gcc-bugs mailing list