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.
