https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27109
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
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.
