Bug 42436 - VRP should mark non-trapping integer divisions
Summary: VRP should mark non-trapping integer divisions
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.5.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization
Depends on:
Blocks: VRP 42108
  Show dependency treegraph
Reported: 2009-12-19 19:40 UTC by Richard Biener
Modified: 2022-01-13 07:13 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2009-12-19 19:42:12


Note You need to log in before you can comment on or make changes to this bug.
Description Richard Biener 2009-12-19 19:40:43 UTC
In PR42108 a division is found to be non-trapping by VRP but neither PRE nor
LIM can make use of that information (well, because VRP doesn't mark the
divisions in any meaningful way).
Comment 1 Richard Biener 2009-12-19 19:42:12 UTC
I'll take care of this during 4.6 development.
Comment 2 Richard Biener 2019-07-31 08:27:33 UTC
Andrew is now maintaing VRP.
Comment 3 Andrew Macleod 2022-01-12 16:14:34 UTC
What needs to be done here? anything?  

Looking at VRP1, there is only a single divide left at that point:

countm1.6_54 = _12 / _13;

and VRP1 is setting the global range of _13 to:

_13: unsigned int [2, 2147483647]

So at least from that point on, it is trivial to determine the divide is non-trapping even using the global ranges.
Comment 4 Richard Biener 2022-01-13 07:13:02 UTC
I think this was trying to cover things like

  if (d != 0)
    tem = a / d;

where the non-zero range of d on the division cannot be put in global ranges
for its SSA name since that would be incorrect for uses not guarded by the
condition.  So it would ask for a new flag on GIMPLE statements to mark the
division not trapping (like we have TREE_THIS_NOTRAP).  Transforms like
PRE or LIM that do code motion of course have to be careful to not move
the stmt outside of the condition that made it not trapping - something which
would be as hard to guarantee as computing the non-trappingness in the first

So yes, the case that made me file this bug is fixed with global ranges.

Let's close this bug since it's quite unspecific.