Simplifier fuzz test failure

[dsharletg]

Simplify fuzz test seed: 1620756761
a = (int8)-26
b = int8((int0)d)
c = (int8)113
d = (int8)84
e = (int8)52
int8x2((uint8x2)absd(((x2(int8((int0)c))/x2((int8)-71)) % (ramp(int8((int0)e), int8((int0)c), 2) % ramp(int8((int0)e), int8((int0)b), 2))) % ((ramp(int8((int0)b), int8((int0)b), 2)*int8x2(ramp((int16)13966, (int16)7221, 2))) - ((x2(int8((int0)b)) % x2(int8((int0)e))) + (ramp(int8((int0)e), int8((int0)a), 2) % ramp(int8((int0)b), int8((int0)c), 2)))), ramp(select((int8)55 == (max(int8((int0)a), (int8)107) + (int8)81), select((int8)117 == int8((int0)a), int8((int0)b), int8((int0)e)), int8((int0)c)), (int8)120, 2)))
int8x2((uint8x2)absd((x2(int8((int0)c)/(int8)-71) % (ramp(int8((int0)e), int8((int0)c), 2) % ramp(int8((int0)e), int8((int0)b), 2))) % ((ramp(int8((int0)b), int8((int0)b), 2)*int8x2(ramp((int16)13966, (int16)7221, 2))) - ((ramp(int8((int0)e), int8((int0)a), 2) % ramp(int8((int0)b), int8((int0)c), 2)) + x2(int8((int0)b) % int8((int0)e)))), ramp(select(max(int8((int0)a), (int8)107) == (int8)-26, select(int8((int0)a) == (int8)117, int8((int0)b), int8((int0)e)), int8((int0)c)), (int8)120, 2)))
In vector lane 0:
int8((uint8)absd((int8)0, select(max(int8((int0)a), (int8)107) == (int8)-26, select(int8((int0)a) == (int8)117, int8((int0)b), int8((int0)e)), int8((int0)c)))) -> (int8)113
int8((uint8)absd((int8)0, select(int8((int0)a) == (int8)-26, select(int8((int0)a) == (int8)117, int8((int0)b), int8((int0)e)), int8((int0)c)))) -> (int8)52

[rootjalex]

Bug seems to be that this rule:

Halide/src/Simplify_EQ.cpp

Line 90 in 3dce2d5

rewrite(max(x, c0) + c1 == 0, x == fold(-c1), c0 + c1 < 0) ||

is being triggered incorrectly, to rewrite this expression:

(max(int8((int0)a), int8(107)) == int8(-26)) -> (int8((int0)a) == (int8)-26)

I'm not quite sure why the predicate is evaluating to true, but am checking it out

[rootjalex]

Ah, it's an overflow bug in the simplifier int8(107) + int8(26) = -123. Not quite sure how this should be handled. I imagine many predicates might need overflow checking guards. @abadams any thoughts?

Edit: to be more specific, constant_fold_bin_op<Add> is overflowing for this expression, which incorrectly allows the predicate to evaluate to true.

[abadams]

I think the fix is that those rules should only trigger for no_overflow_int LHS and RHS to the ==

[rootjalex]

Is it worth adding an IRMatcher wrapper to check if overflow happens in constant folding? That way the rule could still trigger if constant folding doesn't happen. i.e. something like:

rewrite(max(x, c0) + c1 == 0, x == fold(-c1), no_overflow(c0 + c1) < 0) ||

[abadams]

The IRMatcher does check for overflow, for types where overflow is UB. Predicates don't match if there was overflow computing it. For int8 overflow is just well-defined integers-modulo-256 addition.

We could adjust the predicate I guess to something more complex, but I think this rule only really matters for Int(32), so I'd just restrict it to no_overflow_int like most similar rules are.