Kinda like PR 14490 but for the -fwrapv and unsigned cases: void bar (void); void foo (unsigned a) { if (a < 100) return; if (200 < a) return; if (a - 10 > 150) bar (); }
Confirmed. compare_values needs to be teached to look at value ranges for operands and decide on overflow there - but only for substitute and fold as earlier we can have invalid intermediate value ranges.
This seems to be well handled in reassoc1 now: Optimizing range tests a_2(D) -[0, 99] and +[0, 200] and -[10, 160] into a_2(D) + 4294967135 <= 39
Here is a better testcase: void bar(void); void goo(void); void foo (unsigned a) { if (a < 100) return; goo(); if (200 < a) return; if (a - 10 > 150) bar (); } Note the original testcase is optimized correctly in reassoc1 but that was not the point of it. Anyways we have: # RANGE [90, 190] NONZERO 255 _1 = a_3(D) + 4294967286; if (_1 > 150) 4294967286 is -10
well, in evrp we now produce: =========== BB 6 ============ Imports: a_3(D) Exports: _1 a_3(D) _1 : a_3(D)(I) a_3(D) unsigned int [100, 200] <bb 6> : _1 = a_3(D) + 4294967286; if (_1 > 150) goto <bb 7>; [INV] else goto <bb 8>; [INV] _1 : unsigned int [90, 190] 6->7 (T) _1 : unsigned int [151, 190] 6->7 (T) a_3(D) : unsigned int [161, 200] 6->8 (F) _1 : unsigned int [90, 150] 6->8 (F) a_3(D) : unsigned int [100, 160] we know its not going to overflow. who or what should make the decision? looks like some sort of simplification or peephole. Also note that you can now find this out from any pass with the range_query infrastructure that Aldy added: at the start of the pass call enable_ranger() for context sensitive info, and then anywhere you can get_range_query()->range_of_expr (r, stmt, name) will get a range. so for the initial stmt 1 = a_3(D) + 4294967286; asking for the range of a_3 on this stmt would give you [100,200] or asking for the range of the stmt (or i_1 in the next statetment) will give you [90,190] Aldy has also implemented an overflow checker for expressions.. not sure it applies to stmts.. yet. If any of this interests you, send him a note. We're still working out user case functionality, so if there is anything else we need to present this kind of info, let us know. I think he's planning to write a guide for this next week. Another option is to work it backwards. given the stmt: # RANGE [90, 190] NONZERO 255 _1 = a_3(D) + 4294967286; range-ops can tell you that if _1 is [90,190] then it can evaluate the expression and solve that a_3 is [100,200].. if that helps. internally it knows if there was a potential overflow, but that isnt exported in any useful way way at the moment.
*** Bug 101815 has been marked as a duplicate of this bug. ***
Another testcase which shows up via the autovectorizer aliasing checks int g(unsigned int a) { if (a == 0) __builtin_unreachable(); unsigned int t = a; a += -1; return a > 3u; }
I suspect we could add it to simplify_compare_using_ranges_1 very easy. Let me look into that.