[Bug middle-end/69526] ivopts candidate strangeness

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rdapp from comment #10)
> Created attachment 38144 [details]
> Tentative patch for VRP and loop-doloop
> 
> Meanwhile I found the time to implement a pattern for VRP which seems to do
> the job on tree level. Although larger now (and not many cases are covered
> yet) I suppose I agree that it fits better in VRP than in ivopts and might
> even catch more cases than before.
> 
> The fix on RTL level is nonetheless necessary since doloop calculates the
> number of iterations independently of the code before and also adds a +1.
> I cleaned up the fix a little by introducing niterp1_expr (niter plus 1) but
> there's still room for improvement.
> 
> No regressions so far, improvement ideas welcome.

It's a bit very ad-hoc (looking at the VRP part).  I think what we'd need to
do is

  a) in VRP have a general helper telling you whether UNOP A or A BINOP B
  overflows/underflows

  b) in the existing patterns that would handle this and similar situations
  in match.pd:

    /* (A +- CST) +- CST -> A + CST  */
    (for outer_op (plus minus)
     (for inner_op (plus minus)
...

  use such a generic predicate to handle cases with (A +- CST) wrapped
  inside a conversion (it should already be fine to handle this case
  if A +- CST cannot overflow because TYPE_OVERFLOW_UNDEFINED).

  c) use fold_stmt (or gimple_simplify directly) in vrp_fold_stmt to
  invoke the folding machinery - eventually simply unconditionally
  call fold_stmt in
tree-ssa-propagate.c:substitute_and_fold_dom_walker::before_dom_children rather
  than only when we progagated into a stmt.

Even when doing the "ad-hoc" thing initially splitting out a) (implementing
only a subset of operations) would be a useful thing to do.  Note that
during VRP itself you can use its own lattice while when not in VRP you'd
have to rely on SSA_NAME_RANGE_INFO.